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Abstract of EP1 322089 

A mobile station (MS) can be dynamically loaded 
with protocol objects during operation. A protocol 
relay station (MARC) communicates with the 
mobile station via a wireless access network and 
with an Internet protocol partner (CH). An access 
network protocol for communicating via the 
wireless access network is converted into an 
Internet protocol and vice versa. <?? 
independent claims are also included for a 
protocol relay station for communicating with a 
mobile station via a wireless access network and 
for a communications system for connecting 
mobile stations to Internet-protocol partners. 
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(54) Vorrichtungen und System zur dynamischen Protokollanbindung von drahtlosen mobilen 
Stationen an Internet-Protokoll-Netzwerke 



(57) Kommunikationssystem (SOCKLETS-Sy- 
stem) zur Anbindung von Mobilen Stationen (WIS) an 
Internet-Protokoll Partner (CH), welches zumindest ei- 
ne Mobile Station (MS) zur Kommunikation mit einem 
Internet-Protokoll Partner (CH), die zur unmittelbaren 
Kommunikation iiberein drahtloses Zugangsnetz mit ei- 
ner Protokoll Relais Station (MARC) eingerichtet ist, 
uber die sie die dann die mittelbare Kommunikation uber 
ein Internet-Protokoll-Netz, vorzugsweise das offentlich 
zugangliche Internet, mit dem Internet-Protokoll Partner 



(CH) flihrt, wobei die Mobile Station (MS) mit minde- 
stens einem Protokollobjekt wahrend des Betriebes dy- 
namisch geladen werden kann und zumindest eine Pro- 
tokoll Relais Station (MARC) zur Kommunikation mit ei- 
ner Mobilen Station (MS) uber ein drahtloses Zugangs- 
netz einerseits und mit einem Internet-Protokoll Partner 
(CH) andererseits ; wobei sie das Zugangsnetzprotokoll 
zur Kommunikation uber das drahtlose Zugangsnetz in 
das Internet-Protokoll und umgekehrtdas Internet-Pro- 
tokoll in das Zugangsnetzprotokoll umsetzt aufweist. 
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Beschreibung 

[0001] Die vorliegende Erfindung betrifft Vorrichtungen und System zur dynamischen Protokollanbindung von draht- 
losen Mobilen Stationen an Internet-Protokoll Netzwerke. 

5 [0002] Es ist bekannt, daB die Kommunikation zwischen Geraten durch Protokolle geregelt wird. Um die Design- 
komplexitat niedrig zu halten und um das Entwickeln von Protokollen in Telekommunikations- und Computernetzwerken 
zu erleichtern, sind die Protokolle in Schichten unterteilt. Diese Schichten werden funktionell in Stapel organisiert - als 
Protokollstapel. Die Anzahl der Schichten, ihre Namen, Inhalte und ihre Funktionalitat sind oft unterschiedlich fur die 
unterschiedliche Netzwerkarchitekturen. Allen Netzwerkprotokollen ist gemeinsam, daB jede Schicht als Diensterbrin- 

10 gerfurdiedaruberliegenden und als Dienstnehmerfiirdie darunterliegende Schicht wirkt - unter der niedrigsten Schicht 
befindet sich das physikalische Medium. Zwischen zwei aufeinander folgenden Schichten gibt es eine Schnittstelle, 
die die Operationen und Dienste des Diensterbringers definiert und diese dem Dienstnehmer bekannt macht bzw. 
bereitstellt. Innerhalb einer Schicht konnen Unterschichten auftreten. 

[0003] Als Referenzmodell fur die meisten Protokollstapel dient das von der International Standards Organization 
15 (ISO) definiertesiebenschichtige"Open Systems Interconnection" Referenzmodel", kurz OSI (siehehierzu auch Fig. 1). 
[0004] Derweitverbreiteteste Protokollstapel ist der Internet Protokollstapel (siehe hierzu auch Fig. 2), bestehend aus 

einer Netzwerkschicht, genannt "Internet"-, oder kurz IP-Protokoll Schicht, definiert in IETF RFC 791 (Internet 
Emgineering Task Force Request For Comments 791), 

20 

einer Transport-Schicht mit dem "Transport Control Protocol", kurz TCP, definiert in IETF RFC 793 (Internet Em- 
gineering Task Force Request For Comments 793) und dem "User Datagram Protocol", kurz UDP, definiert in IETF 
RFC 768 (Internet Emgineering Task Force Request For Comment 768). 

25 [0005] Diese Standards werden durch weitere Standards des Internet Engineering Task Force, IETF, verfeinert. Der 
Internet-Protokollstapel wird oft "TCP/IP" genannt. 

[0006] Der TCP/I P-Protokollstapel ist unter der Annahme entwickelt worden, daB das physikalische Ubetragungs- 
medium wahrend einer Sitzung sich nicht andert bzw. immer dasselbe ist, z.B. Kupferkabel, und in seinen Eigenschaf- 
ten weitgehend stabil bleibt. So ist das TCP/IP fur kabelverbundene Netzwerke, die aus sogenannten Fixed-Hosts 

30 bestehen, entwickelt worden und berucksichtigt die Eigenschaften nur solcher Ubertragungsmedien. TCP ist vom De- 
sign her fur drahtlose Netzwerke ungeeignet, da sein Korrektur- bzw. seine Sicherungsmechanismen von Stauung 
(Congestion) und nicht von Fehlern auf dem Ubetragungmedium ausgehen. Wegen derhohen Ubertragungsfehlerrate 
in drahtlosen Netzwerken gehen jedoch viele Datenpackete verloren. Das wird vom TCP als Stauung miBverstanden 
und aktiviert seine Stauungs-Vermeindungs (Congestion Avoidance) Algorithmen. Dies hat dann eine groBere Uber- 

35 tragungs-Verzogerung (Delay) und einen niedrigeren Durchsatz zur Folge. 

[0007] Die Bedeutung mobiler und drahtloser Netzwerke fur den Zugriff auf Internet-Dienste nimmt aberstandig zu. 
Konsumenten benutzen mobile Gerate, die sowohl drahtgebundene als auch drahtlose Ubertragunstechnologien un- 
testutzten mussen, um mit anderen uber das Internet und unter Benutzung des Internet-Protokollstapels zu kommu- 
nizieren. TCP nutzt leiderdie Eigenschaften der drahtlosen Netze nicht optimal und u.U. hat TCP hierbei sogar negative 

40 Auswirkungen auf den gesamten Durchsatz. Es sind nicht immer nur langsame drahtlose oder drahtgebundene Netz- 
werktechnologien, wie GSM (GSM: Groupe Special Mobil) oder Modem-Verbindungen, als Verursacher schlechter 
Performance auszumachen, sondern auch Internet-Protokollstapel, die die Eigenschaften solcher Ubertragungstech- 
nologien nicht berucksichtigen. Viele Mechanismen sind entwickelt worden, um insbesondere TCP an die Eigenschaf- 
ten der drahtlosen Ubertragung, etwa der Funkubertragung, anzupassen. So sind dem Protokoll weitere Optionen und 

45 zusatzliche Mechanismen zur Retransmission zugefugt worden, wie z.B. die "Selektive Bestatigung" (Selective ACK- 
nowledgement) (SACK) Option, beschrieben in IETF RFC 2018 und IETF RFC 2883, und derTCP-Eifel Algorithmus 
(vgl. R. Ludwig, "Eliminating Inefficient Cross-Layer Interactions in Wireless Networking", Dissertation, Technische 
Hochschule Aachen, Deutschland, April 2000). 

[0008] Der Zugang von privaten zu offentlichen und von drahtlosen zu drahtgebundenen Netzwerken findet immer 
50 uber sogenannte Zugangspunkte (auch Basisstationen oder Access Points genannt), statt, die meist zwei unterschied- 
liche Ubertragungstechnologien verbinden. Sie implementieren die zwei untersten Protokollschichten des OSI-Refe- 
renzmodells und somitsind diese Zugangspunkte fur TCP, welches ein Protokoll fur Punkt-zu-Punkt Verbindungen auf 
der Transport-Schicht ist, transparent. Diese Heterogenitat der Ubetragungstechnologien der beteiligten Netzwerke 
war im Design des TCP nicht vorgesehen. Aufgrund der unterschiedlichen Signallaufzeiten in den heterogenen Netz- 
55 werken wird TCP zu einem "Fehlverhalten" verleitet, welches starke Performance-Einbruche hervorruft. Es sind meh- 
rere Mechanismen vorgeschlagen, die die Eigenschaften des darunterliegenden Ubertragungsmedium dem TCP be- 
kannt machen wollen, damit TCP sein Verhalten entsprechend anpaBt. Diese Mechanismen sehen ein Verbindungs- 
aufsplittung der TCP Ende-zu-Ende Verbindung vor, und zwar an der Basisstation. Bekannte Vertreter dieser Methode 



2 



EP 1 322 089 A2 



sind, "Snoop" (vgl. S. Balakrishnan, E. Amir Seshan, und R.H. Katz: "Improving TCP/IP performance over wireless 
networks", 1st Intl. MobileComputing and Networking [MOBICOM'95], Berkeley, Nov. 1995), Indirect-TCP (vgl. A. Bakre 
und B. Badrinath, "l-TCP: Indirect TCP for mobile hosts", Proc. 15 th International Conf. on Distributed Computing 
Systems [ICDCS], May 1995), MTCP (vgl. K.Brown und S. Singh, "M-TCP: TCP for mobile cellular networks", ACM 

5 Computer Communications Review, vol. 27, no. 5, 1997). 

[0009] Zudemfuhrtdie Mobilitat und derdamit verbundene Wechsel zwischen Funkzellen. Handover genannt, durch 
seine grosse Verzogerungsvarianz (delay variation) und Datenverluste zu falschen Einschazungen derZeitgeberwerte 
in derTCP Zustandsmaschine. Das Ergebnis ist eine drastische Verschlechterung der Performance. 
[0010] Daruberhinaus ist die Komplexitat des TCP/IP Protokollstapels sehrhoch woraus einesehr ressourceninten- 

10 sive Aktivitat resultiert. Wenn der TCP/IP Stapel eines Gerates aktiviert wird, dann steigt der Energieverbrauch sehr 
stark an, mit dem Ergebniss, daB batteriebetriebene Gerate eine stark verkurzte Wirkungszeit im Vergleich zu ihrem 
TCP/IP-losen Einsatz haben. TCP/IP beanspruchtmehr als 60% der Funktionalitat eines Protokolstapels und ca. 30%- 
70% der operativen Ressourcen eine Betriebssystems. 

[0011] Die internationale "Software Defined Radio" Initiative, SDR (vgl. Software Radio, Special Issue of the IEEE 

'5 Personal Communications Magazine, Vol. 6 No. 4, Aug. 1999), sieht die Enwicklung von Hardware-unabhangigen 
Radiotransceivern vor, und zwar mittels extensiver Nutzung von Digitalen Signal Prozessoren, DSPs. SDR-Module 
sollen sowohl in den mobilen Endgeraten als auch in den Basisstationen implementiert werden. Durch SDR kann die 
funkbezogene (Radio-)Funktionalitat der Gerate modifiziert werden. Dabei werden die untersten zwei Protokollschich- 
ten des OSI Referenzmodells beeinflusst, der TCP/IP Protokollstapel bleibt unberuhrt. 

20 [0012] DSPs sind machtige Hardware-Bausteine, die der Realisierung der SDR-Module dienen, die sie benotigen, 
um hiermit die aufwendige und Ressourcen-intensive Funktionalitat mehrerer Funktechnologien zu gewahrleisten. 
[0013] Sogenannte Protoko II -Booster, (vgl. W.S. Marcus, I. Hadzic, A.J. McAuley. J.M. Smith, Protocol Boosters: 
Applying Programmability to Network Infrastructures, IEEE Communications Magazine, vol. 36, no. 10, pp. 79-83, 
2000), (vgl. I. Hadzic, Applying Reconfigurable Computing to Reconfigurable Networks, PhD, Thesis, 1 999), sind Hard- 

25 ware-, seltener Software-Module, die Kommunikationsgerate mit zusatzliche Funktionalitaten versehen. Sie erhohen 
zwar das Angebot an Funktionalitaten am Endgerat. tragen aber nur der Performance-Steigerung in festverdrahteten 
Netzen bei. Protocol-Booster basieren auf programmierebarer Hardware, FPGA, die zusatzliche Hardware-Programm- 
logik auf den Endgeraten benotigen und somit zu einer Erhohung des Energieverbrauchs, des Gewichtes und bei 
mobilen Geraten auch der GroBe beitragt. 

30 [0014] Alle heutige Ansatze gehen, um bessere Performance zu erzielen, von einer "Modifikation" bzw. "Erganzung" 
des Gerates durch Zusatze aus, wobei die benotigten Hard- und/oder Softwareteile fur diese Modifikation/Erganzung 
schon im Gerat - inaktiv - vorhanden ist. Dies hat zur Folge, daB Speicher- und Energieressourcen dafur bereitgestellt 
werden mussen, auch wenn diese Zusatze nur auRerst selten benutzt werden. 

[0015] Auch ist heute ein Hauptziel moderner Systeme die transparente Bereitstellung von Diensten, unabhangig 
35 von derdarunterliegendenTransporttechnologie(ISDN, GSM, HIPERLAN, IEEE802.11, Bluetooth, usw.). Diese Trans- 
parenz und Unabhangigkeit wird heute nur zum Teil erreicht und zwar durch 

(a) bedingt rekonfigurierbare Terminals und 

40 (b) programmierbare Netzwerke (Anm.: Adaptive Systeme optimieren oderpassensich automatisch wahrend ihres 

Betriebes an die Gegebenheiten an. Programmierbare Systeme dagegen sind so entworfen, dafB Benutzern er- 
moglicht wird, durch ein Interface oder durch ein Programmierungsmodell, das Systemverhalten zu andern). 

[0016] Im einzelnen: 

45 

(a) Rekonfiguration von mobilen, drahtlosen Terminals findet heute auf folgende Ebenen start: 

Auf Applikationsebene : Hier werden mittels verschiedener Browser, Applikationen geladen und ausgefiihrt, 
wie z.B. JAVA - Applets. Diese Art der Rekonfiguration ist fur mobile Gerate, wie z.B. Personliche Digitale 
50 Assistenten, PDAs, und mobile Telefone, in dem MExE (MExE: Mobile Station Application Execution Environ- 

ment, definiert in 3GPP TS 22.057) Vorschlag vorgesehen. 

Auf Netzwerkebene : Eine sehr eingeschrankte Konfigurationsmoglichkeit ergibt sich hier, indem die IP-Adres- 
se automatisch vergeben werden kann (DHCP [DHCP: Dynamic Host Configuration Protocol, definiert in RFC 
55 21 31] Dienst). Fur nicht IP-fahige Gerate gibt es keine Rekonfigurationsmoglichkeit. 

In derphysikalischen Schicht (inkl. Medium Access Control [auch Media Access Control], MAC, Sub-Schicht): 
Drahtlose Terminals konnen in heterogenen Umgebungen operieren, indem sie mehrere Funkmodems, z.B. 
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eines fur GSM und eines fur DECT, oder Multiband Modems aufweisen. Solche Gerate entsprechen nur den 
Anforderungen von Basisdiensten, z.B. Sprachubertragung. Im Rahmen der "Software Defined Radio", SDR, 
Initiative wird ein Modem mehrere Funktechnologien unterstiitzen. 

5 (b) Programmierbare oder "Aktive Netzwerke" erlauben Anderungen der Funktionalitat von Netzwerkknoten in 

lokalen Netzen (auch in Backbones), entweder durch Applikationen oder durch Benutzervorgaben. Einfache Bei- 
spiele, die von Applikationen gesteuert werden, sind Web- und Applikations-Level Proxies (Firewalls). In der. 
drahtlosen Welt 1 findet man Protocol Booster, Applikations-Proxies und sogenannte ,Loss Indication'-Mechanis- 
men. Viele dieser Konzepte sind im Zugangsnetz (Access Network) realisierbar, daher konnen sie als Komponen- 

10 ten von Aktiven Netzwerkknoten betrachtet werden. Aktive Netzwerke werden das Ruckgrad der Kommunikation 

der4ten Generation bilden. Sie bieten das Potential, urn Zeit und Kosten zur Einfiihrung neuer Dienste und Pro- 
tokolle drastisch zu reduzieren - man vergleiche mit dem muhsamen Upgrade der GSM Netze zu GPRS! 

[0017] Alle aufgefuhrte Methoden haben jedoch negative Nebenwirkungen, wie z.B. die Unterbrechung der Dienst- 
15 bereitstellung, den Verlustvon Applikationsdaten, oder aber sie zwingen zur zeitlichen Unterbrechung der Verbindung 
mit anschliessendem Neuaufbau. 

[0018] Die Rekonfiguration auf Applikationsebene erlaubt zwar die Anpassung der Arbeits- und 
[0019] Ausfuhrungsumgebung an die personlichen Vorgaben der Endbenutzer, berucksichtigt aber keineswegs die 
Heterogenitat der Netze oder der Ressourcen. Sowohl beim Ubergang von einer Funkzelle in die nachste (horizontales 
20 Handover) als auch beim Ubergang von einer Ubertragungstechnolgie in eine andere (vertikales Handover) sind 
Dienst- und Applikationsunterbrechungen moglich. Zudem ist die Rekonfiguration auf physikalischer Ebene sehr res- 
sourcenintesiv und bis heute sehr schlecht geeignet fur kleine und kleinste mobile Gerate. 

[0020] Moderne Kommunikation basiert jedoch auf Systemen die sich schnell an neue Aufgaben anpassen lassen 
und sowohl Benutzer- als auch Terminalmobilitat unterstutzen mussen. Drahtlose Gerate mussen in variablen Umge- 

25 bungen funktionieren, in denen unterschiedliche Technologien und Netzbetreiber vorkommen. Dies umfaBt verschie- 
dene drahtlose Technologien fur Licht- (Laser, Infrarot). oder Funkubertragung, groBe Varianz von Bit-Fehlerraten. ein 
breites Spektrum von Ubertragungsraten (von 9.6kbps in GSM bis 54Mbps in HIPERLAN/2), verschiedene Frequenzen 
und Modulationsverfahren und schliesslich eine groBe Anzahl von Protokollen. Diese Einsatzvariabilitat schliesst un- 
terschiedliche Mobilfunkbetreiber und Operatoren mit ein, welche proprietare Abrechnungssysteme (Charging, Ac- 

30 counting und Billing Systeme) einsetzen. Dies zu gewahrleisten, ist der vorstehend erauterte Stand derTechnik aus 
den geschilderten Grunden jedoch nur unzureichend in der Lage. 

[0021] Zuammenfassend gesehen ist daher der bereits skizzierte relevante Stand der Technik vor dessen Hinter- 
grund sich die Aufgabe der vorliegenden Erfindung stellt, durch folgende Dokumente gegeben: 



35 - s. Balakrishnan, E. Amir Seshan, and R.H. Katz: "Improving TCP/IP performance over wireless networks", 1st 
Intl. Mobile Computing and Networking (MOBICOM'95), Berkeley, Nov. 1995. 

A.Bakre and B. Badrinath, "l-TCP: Indirect TCP for mobile hosts", Proc. 15 th International Conf. on Distributed 
Computing Systems (ICDCS), May 1995. 

40 

K.Brown and S. Singh, "M-TCP: TCP for mobile cellular networks", ACM Computer Communications Review, vol 
27, no 5. 1997. 



A. Fox, S. Gribble, E. Brewer, E. Amir: Adapting to Network and Client Variability via On-Demand Dynamic Distil- 
45 lation. Proc. Seventh International Conference on Architectural Support for Programming Languages and Opera- 

ting Systems (ASPLOS-VII), Oct. 1 996, Cambridge, MA (Betrifft nur die ubertragene Daten, die hier entweder nur 
teilweise geladen werden, damit der Benutzer entscheiden kann ob er die Daten doch braucht oder nicht, oder in 
Abhangigkeit des Datentyps (Video, Audio, reine Daten) entsprechende Kompressionsalgorithmen vor dem Daten- 
Downloaded zu benutzen. Die Autoren beschranken sich auf dem Applikationslevel). 

50 

Tom Goff, James Moronski, Dhananjay S. Phatak, Vipul Gupta, "Freeze-TCP: A True End-to-End TCP Enhance- 
ment Mechanism for Mobile Environments", Proc of IEEE Infocom 2000. 



I.Hadzic. Applying Reconfigurable Computing to Reconfigurable Networks, PhD. Thesis. 1999. 

55 

R. Ludwig, "Eliminating Inefficient Cross-Layer Interactions in Wireless Networking", Dissertation, Technische 
Hochschule Aachen, Deutschland, April 2000. 
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W.S. Marcus, I. Hadzic, A.J. McAuley, J.M. Smith, Protocol Boosters: Applying Programmability to Network Infra- 
structures, IEEE Communications Magazine, vol. 36, no. 10, pp. 79-83, 2000. 

R.E.Schuh, C.Schuler, M.Mateescu, "An Architecture for Radio-Independent Wireless Access Networks", Proc. of 
5 the 49 th IEEE Annual International Vehicular Tech n. Conf. VTC'99, Vol 2, pp 1227-1231, May 1999, Houst, Texas, 

USA. 

G. Welling and B. R. Badrinath: A Framework for Environment Aware Applications: In Proceedings of the 17 th 
ICDCS Conference, Baltimore, Maryland, May 1997. 

10 

- G.R.Wright, W.R.Stevens: TCP/IP-Illustrated, Vol. 1 -3, Addison-Welsey, 1995. 

Software Radio, Special Issue of the IEEE Personal Communications Magazine, Vol. 6 No. 4, Aug. 1999. 

15 [0022] Auch die nachfolgenden 3GPP Dokumente sind dabei als relevanter Stand der Technik zu berucksichtigen, 
welche derzeit unter http://www.3gpp.org gefunden werden konnen: 

3G TS 22.057: "Mobile Station Application Execution Environment (MExE)" 

20 - 3G TS 22.060: "General Packet Radio Service (GPRS); Service description; Stage 1". 

3G TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". 

3GTS 23.121: "Architectural Requirements for Release 1999". 

25 

3G TS 25.301 : "Radio Interface Protocol Architecture". 
3G TS 25.303: "Interlayer Procedures in Connected Mode". 
30 - 3G TS 25.322: "RLC Protocol Specification". 

3G TS 25.331 : "RRC Protocol Specification". 
■ 3G TS 25.401 : "UTRAN Overall Description". 

35 

- 3G TR 25.990: "Vocabulary for the UTRAN". 

3G TS 27.060: "General Packet Radio Service (GPRS); Mobile Station (MS) supporting GPRS". 

40 [0023] Ebenso sind auch die nachfolgenden RFC (Request fur Comments) Dokumente dabei als relevanter Stand 
der Technik zu berucksichtigen, welche derzeit unter http://www.ietf.org gefunden werden konnen: 

- IETF RFC 768 (1980): "User Datagram Protocol" (STD 6). 
45 - IETF RFC 791 (1981): "Internet Protocol" (STD 5). 

IETF RFC 792 (1981): "Internet Control Message Protocol" (STD 5). 

- IETF RFC 793 (1981): "Transmission Control Protocol" (STD 7). 

50 

- IETF RFC 1661 (1994): "The Point-to-Point Protocol (PPP)" (STD 51). 

- IETF RFC 2002 (1996): "IPv4 Mobility Support". 

55 - IETF RFC 2018 (1996): "TCP Selective Acknowledgement Options". 
IETF RFC 2131 (1997): "Dynamic Host Configuration Protocol". 
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IETF RFC 2475 (1998): "An Architecture for Differnetiated Services". 

- IETF RFC 2692 (1999): "SPKI Requirements". 

5 - IETF RFC 2883 (2000): "An Extension to the Selective Acknowledgment (SACK) Option for TCP" 

[0024] Angesichts dervorstehenden Ausfuhrungen istesvor dem Hintergrund dieses Standes derTechnik Aufgabe 
der vorliegenden Erfindung Vorrichtungen anzugeben, die eine moglichst flexible Anbindung einer Mobilen Station an 
einen Internet-Protokoll Partner erlauben, dabei aber auch sowohl die schlechte Leistung insbesondere des TCP-Pro- 
10 tokolls in drahtlosen Netzen als auch den hohen Ressourcenverbrauch bei zwingender Verwendung eines Internet- 
Protokollstapels in der Mobilen Station zu vermeiden hilft. 
[0025] Diese Aufgabe wird sowohl durch 

eine Mobile Station (MS) zur Kommunikation mit einem Internet-Protokoll Partner, auch Correspondent Host (CH) 
15 genannt. die zur unmittelbaren Kommunikation uber ein drahtloses Zugangsnetz mit einer Protokoll Relais Station 

(MARC) eingerichtet ist, uber die sie die dann die mittelbare Kommunikation uber ein Internet-Protokoll-Netz, 
vorzugsweise das offentlich zugangliche Internet, mit dem Internet-Protokoll Partner (Correspondent Host, CH) 
fuhrt 

gelost, die erfindungsgemaR dadurch gekennzeichnet ist, 
20 daf3 die Mobile Station (MS) mit mindestens einem Protokollobjekt der Schichten 2 bis 4 (Fig. 1 und 2) wahrend 

des Betriebes dynamisch geladen werden kann. 

[0026] Vorzugsweise kann dabei die Mobile Station (MS) mit einem Zugangsnetzprotokollstapel als Protokollobjekt 
zur Abwicklung des Zugangsnetzprotokolls zur Kommunikation uber das drahtlose Zugangsnetz wahrend des Betrie- 
25 bes dynamisch geladen werden. 

[0027] Die Erfindung wird jedoch auch durch das Gegenstiick hierzu, namlich durch 

eine Protokoll Relais Station, auch Mobile Access & Router Controller genannt (MARC) zur Kommunikation mit 
einer Mobilen Station (MS) uber ein drahtloses Zugangsnetz einerseits und mit einem Internet-Protokoll Partner 
30 (Correspondent Host, CH) andererseits, 

gelost, welche erfindungsgemaB dadurch gekennzeichnet ist, 

dafB sie das Zugangsnetzprotokoll zur Kommunikation uber das drahtlose Zugangsnetz in das Internet-Protokoll 
und umgekehrt das Internet-Protokoll in das Zugangsnetzprotokoll umsetzt und daB der MARC mit mindestens 
einem Protokollobjekt wahrend des Betriebes geladen werden kann. 

35 

[0028] Durch beide vorstehenden Komponenten Ia3t sich ein Kommunikationssystem, SOCKLETS-System genannt 
bilden. Das SOCKLETS-System ermoglicht das Austauschen von Protokollobjekten, vorzugweise Protokollstapeln 
und ist applikationstransparent. Es ermoglicht so eine applikationstransparente Optimierung der drahtlosen Kommu- 
nikationsdienste. Das SOCKLETS System unterstutzt dabei einerseits die dynamische Rekonfiguration der Endgerate 

40 auf Netzwerkebene durch Code-Mobilitat und andererseits auch die dynamische Optimierung der Zugangsnetze. 

[0029] Mobile Stationen und Terminals waren bisher nur auf Applikationsebene bzw. auf physikalischer Ebene re- 
konfigurierbar. Es ist daher technisch vorteilhaft eine Rekonfigurationsmoglichkeit aller Protokollschichten wie nach 
der vorliegenden Erfindung hier vorzusehen. Wahrend "Software Defined Radio" nach dem Stand der Tehnik die Ad- 
aptability hinsichtlich von Radiomodems gewahrleistet, konnen austauschbare, spezialisierte und/oder "leichtgewich- 

45 tige'V optimierte DataLink-, Netzwerk- und/oder Transportprotokolle einerseits die Adaptability und damit Flexibility 
zu a-priori unbekannten Zugangen sicherstellen und andererseits auch eine grossere, ressourcenschonende Variabi- 
lity in Qualitatssicherungsmechanismen (Quality of Service) ermoglichen, da sie als Zugangsprotokoll zum Zugangs- 
netz nicht des insbesondere fur drahtlose oder asymmetrische Netze ungeeigneten Internet-Protokollstapels zwingend 
bedurfen. Vielmehr kann das Zugangsnetzprotokoll auf das Ubertragungsmedium angepasst werden und die Umset- 

50 zung auf den Internet-Protokollstapel dem MARC iiberlassen bleiben. 

[0030] Mit Protokollobjekten sind dabei hiersowohl allgemeineKommunikations- und Protokollobjekte, vorzugsweise 
Protokollstapel, gemeint. Sie konnen Kommunikations-, Verwaltungs- und Berechnungsfunktionalitaten bereitstellen, 
wie auch gesamte Protokollschichten oder Protokollstapel. Die Protokollobjekte konnen in Hardware, Software oder 
in einer Kombination von Hard- und Software realisiert werden. 

55 [0031] Der Protokollobjektaustausch ist fur Applikationen vollig transparent und erfolgt per automatischem, halb- 
automatischem oder manuellem "Elnspielen" von Protokollobjekten in das jeweilige Endgerat und/oder in die entspre- 
chende Basisstation. Das "Elnspielen" der Protokollobjekte kann sowohl uber das Kommunikationsnetz (Download) 
als auch durch Laden seitens externertragbarer/mobiler Speichermedien , wie z.B. SmartCards (Pre-paid Cards), PCM- 
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CIA oder PC Cards, SONY(geschutzte Marke)- Sticks, Disketten, MiniDiscs, CompactDiscs, CompactFlash usw. erfol- 
gen. 

[0032] Das Initiieren des Einspielens und das Aktivieren der neuen Protokollobjekte kann manuell durch Schalter- 
stellen, halbautomatisch oder automatisch erfolgen. Diese Objekte konnen sowohl Dienste-Erbringer als auch Dien- 

5 ste-Nehmer sein und kooperieren bei Bedarf miteinander. Nach der Injektion und Aktivierung des neuen Protokollob- 
jekts findet ein "Protokoll-Handover" statt, indem der vertikale Datenfluss zwischen Applikationen und physikalischem 
Netz einen geanderten Pfad folgt. Eine Kontrollinstanz initiiert, aktiviert und uberwacht sowohl das "Protokoll-Hando- 
ver" als auch die entsprechenden Injektions- und 
[0033] Austausch-Verfahren. 

10 [0034] Die Moglichkeit eines Austauschs von Protokollobjekten bietet dabei folgende Vorteile: 

1 . Es besteht die Moglichkeit der Anderung der Qualitatsanforderung (Quality of Service-Anforderung), z.B. Echt- 
zeitanforderungen fur Sprache gegenuber Datenintegritat beim Download uber Nacht eines Videos. Jeweils an- 
gepasste und ressourcenschonende Protokolle und Protokollobjekte konnen so ein optimales Leistungs-/Kosten- 

15 verhaltnis ermoglichen. 

2. Anderung des Abrechnungsmodells. Dadurch konnen Dienste aufgewertet werden, indem sie "im Bundle" mit 
entsprechenden Protokollobjekten angeboten werden . 

20 3. Anderung der operativen Umgebung ; z.B. wechseln von einer offentlichen (Strasse) in eine restriktiven (Kran- 

kenhaus) Umgebung. Obwohl GSM eine globale Abdeckung hat, ist seine Nutzung innerhalb eines Krankenhauses 
untersagt. Die Umgebung bestimmt in diesem Falle ob eine Technologie benutzt werden darf oder nicht. 



[0035] Diese Flexibility durch Adaptability wird durch die vorstehenden erfindungsgemaBen Vorrichtungen bzw. 
25 das hieraus gebildete erfindungsgemaBe SOCKELTS-System erreicht. 

[0036] Hinsichtlich des Verstandnisses von Details der vorstehenden Komponenten und ihrer Funktionsweise wer- 
den sei schon hier auf die Beschreibung im Detail anhand der Figuren und hier zunachst insbesondere auf die Be- 
schreibung zu Fig. 5 und 6 verwiesen. 

[0037] Vorzugsweise ist die Mobile Station (MS) nach der vorliegenden Erfindung so eingerichtet, daf3 sie wahrend 

30 des Betriebes ohne Unterbrechung einer etwaigen Kommunikation mit dem Protokollobjekt, vorzugsweise Protokoll- 
stapel, geladen werden kann. Das Laden derMobilen Station (MS) mit Protokollobjekten, vorzugsweise Zugangsnetz- 
protokollstapeln, erfolgt dabei besonders bevorzugterweise durch die Protokoll Relais Station (MARC) die hierfur in 
einer bevorzugten Ausfuhrungsform nach der vorliegenden Erfindung besonders eingerichtet ist. Dies kann wahrend 
des Betriebes der Mobilen Station (MS) ohne Unterbrechung einer etwaigen Kommunikation erfolgen. Die zugrunde- 

35 liegende Technologie basiert auf dem "On-the-Fly" Einspielen und wird in der nachfolgenden Figurenbeschreibung im 
Detail erlautert, wobei hier insbesondere den Fig. 7. 8, 9, 10 und 12 die Aufmerksamkeit gelten sollte. 
[0038] In einer Ausfuhrungsform nach der vorliegenden Erfindung ist die Mobile Station (MS) zur Kommunikation 
mit einem Internet-Protokoll Partner (CH) dadurch gekennzeichnet. daB die sie so eingerichtet ist, daf3 sie mit minde- 
stens zwei Protokollobjekten, vorzugsweise Zugangsnetzprotokollstapeln gleichzeitig geladen sein kann, wobei be- 

40 vorzugterweise zwischen mehreren geladenen Protokollobjekten, vorzugsweise Zugangsnetzprotokollstapeln, umge- 
schaltet, besonders bevorzugterweise ubertragungsunterbrechungsfrei umgeschaltet, werden kann. Dieser Umschalt- 
vorgang wir dabei in einer weiteren bevorzugten Ausfuhrungsform der Erfindung hier von der Protokoll Relais Station 
(MARC) vorgenommen, die dann sie so eingerichtet ist, daB sie die Mobile Station (MS) zur Umschaltung zwischen 
mehreren geladenen Protokollobjekten, vorzugsweise Zugangsnetzprotokollstapeln, veranlassen kann, wobei auch 

45 dies ubertragungsunterbrechungsfrei geschenen kann. Die zugrundeliegende Technologie basiert auf dem "On-the- 
Fly" Aktivieren von Protokollobjekten innerhalb der mobilen Endgerate und Zuganspunkte (Basisstationen, Access 
Points). Wegen der naheren Details sei hier insbesondere die Fig. 7, 8, 9, 10 und 12 und ihre jeweilige Bechreibung 
verwiesen. 

[0039] In einer weiteren Ausfuhrungsform ist die Mobile Station (MS) zur Kommunikation mit einem Internet-Protokoll 
50 Partner (CH) nach der vorliegenden Erfindung dadurch gekennzeichnet, daB sie so eingerichtet ist, daB unterschied- 
liche geladene Protokollobjekte, vorzugsweise Zugangsnetzprotokollstapel, von der Mobilen Station (MS) auch zur 
Kommunikation uber unterschiedlicheZugangnetzeverwendet werden. Auch kann die Protokoll Relais Station (MARC) 
nach der vorliegenden Erfindung so ausgestaltetsein, daB sie mehrere ; vorzugsweise unterschiedliche, Zugangsnetz- 
protokolle zur Kommunikation uber jeweilige drahtlose Zugangsnetze in das Internet-Protokoll und umgekehrt das 
55 Internet-Protokoll in das jeweilige Zugangsnetzprotokoll umsetzt. Hierdurch ermoglicht die vorliegende Erfindung eine 
dynamische Anderung der Transport- bzw. Kommunikationstechnologie, wie z.B. durch Ubergang von einem offentli- 
chen Netz (GSM, GPRS) in ein privates bzw. lokale Netzs (drahtloses Netz, DECT). 

[0040] Vorzugsweise weist sie auch eine Internet-Protokollstapel Schnittstelle (T-Schnittstelle) auf, auf die auf der 
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Mobilen Station implementierte Applikationen zugreifen konnen. Im mobilen Endgerat wird durch Emulation der Socket 
Funktionalitat ein Zugang zum Internet Protokollstapel (und somit zu alien weiteren Protokoll-Proxies, z.B. IPX) be- 
reitgestellt. Das entsprechende API (API: Application Programming Interface) garantiert, dafB alle Internet Applikatio- 
nen, die die Socket Schnittstelle benutzen, ohne Modifikation funktionieren. 

5 [0041] Die Protokoll Relais Station (MARC) nach der vorliegenden Erfindung kann so ausgestaltet sein, daG siedie 
jeweiligen Protokollobjekte, vorzugsweiseZugangsnetzprotokollstapelzurKommunikation uber das jeweilige drahtlose 
Zugangsnetz, von einem externen Server anfordert, wenn sie sie nicht selbst in ihrem Cache oder ihrer Datenbank 
vorratig hat. Gleiches gilt wenn die Protokoll Relais Station (MARC) das jeweilige Protokollobjekt, vorzugsweise den 
jeweiligen Zugangsnetzprotokollstapel, zum Laden der jeweiligen Mobilen Station (MS) nicht in ihrem Cache oder ihrer 

10 Datenbankfindet, auch dann kann sie es bevorzugterweise von einem externen Server anfordern. Wegen der naheren 
Details hierzu sei insbesondere auf die Fig. 8 und 10 und ihre Beschreibung verwiesen. 

[0042] Zur Kommunikation mit dem jeweiligen Internet Protokoll-Partner (CH) kann die Protokoll Relais Station 
(MARC) sowohl das TCP- Protokoll, wie auch das UDP-Protokoll oder andere geeignete Protokolle verwenden. 
[0043] Die vorliegende Erfindung ermoglicht somit das nahtlose, verlust- und betriebsunterbrechungsfreie Injizieren 

15 und Austauschen von Protokollobjekten, vorzugsweise Zugangsprotokollstapelobjekten oder Protokollstapeln in paket- 
und leitungsorientierten Kommunikationsvorrichtungen, so daB ein optimales Betriebs- und Energiekosten-Leistungs- 
verhaltniszwischen Kommunikationsprotokollstapel und Ubertragungs-Technologie bzw. Ubertragungsmedium erzielt 
wird. Zusatzlich sind aufgrund der Verwendung der Internet- Protokoll Socket API (T-Schnittstelle) keine Anderungen 
an die Applikationen erforderlich. 

20 [0044] Die vorliegende Erfindung weist eine Reihe technischer Vorteile auf. Im Einzelnen: 

[0045] Dadurch, daRfur diejeweils verwendete Ubertragungstechnologie Protokolllobjekte (vorzugsweise Protokoll- 
stapel) dynamisch geladen werden konnen, wird ein Optimum beim Leistungs-Kosten Verhaltnisses bzgl. der Nutzung 
der Ressourcen der Kommunukationsvorrichtung erzielt. 

[0046] Die Erfindung erlaubt eine dynamische Rekonfiguration der Endgerate auf Netzwerkebene, ebenso eine dy- 

25 namische Optimierung der Zugangsnetze. 

[0047] Es ist von Vorteil, Kommunikationsgerate, ohne sie auszuschalten, mit Protokollobjekten vorzugsweise mit 
Protokollstapeln, die fur unterschiedliche Ubertragungstechnologien optimiert sind. auszustatten, so da3 immer eine 
optimale Ausnutzung der Merkmale und Charakteristika des Ubertragungsmediums erzielt werden kann. 
[0048] Auch ist ein Abgleich der Kommunikationseigenschaften zwischen Endgerat und Zugansznetz moglich. 

30 [0049] Mobile Endgerate konnen bei verschiedenartigem Trager (Bearer), von z.B. ISDN. GSM, HI PERL AN/2, eine 
optimale Ressource-Ausnutzung erzielen, indem Netzwerk-, Transport- und Zugangsnetz-Protokolle in Abhangigkeit 
von den Tragereigenschaften (Frequenz, Modulation, MAC, usw.) gewah It werden. Zum Beispiel kann eine Internet- 
Applikation, die auf ein Personal Digital Assistant, PDA, uber ein GSM Modem lauft, ohne vollstandigen TCP/IP Pro- 
tokollstapel mit dem Internet kommunizieren! Wird das PDA in seiner Dockingstation eingesteckt und wird eine Kom- 

35 munikationsverbindung durch Kabel hergestellt, dann kann der vollstandige TCP/IP Protokollstapel ins PDA geladen 
werden - ohne manuelle Umkonfiguration des Gerates und ohne Unterbrechung der Applikation. 
[0050] Mobile Endgerate konnen ihren Energieverbrauch an die Applikationsanforderungen und die Einsatzgege- 
benheiten anpassen. So wird in obigem Beispiel der Energieverbrauch bei der GSM-Ubertragung durch Vermeiden 
der Nutzung des vollstandigen TCP/IP Protokollstapels drastisch reduziert. 

40 [0051] Applikationen und Gerate konnen sich an a-priori "unbekannte" Anforderungen anpassen. 

[0052] Applikationen und Gerate konnen sich an a-priori "unbekanntes" Netzwerkverhalten und Netzcharakteristika 
anpassen. 

[0053] Nicht-lnternet fahige Gerate und konnen mit Diensten des Internet- Protokoll Stapels erweitert werden. 
[0054] Internet Applikationen konnen von verschiedenen Quality of Service Policies (und daraufbauenden Abbrech- 
45 nungsmechanismen) profitieren und auf gewertet werden. 

[0055] Es kann eine applikationstransparente Optimierung der drahtlosen oder drahtgebundenen Kommunikations- 
dienste erfolgen. 

[0056] Die vorliegende Erfindung ermoglicht ein benutzerfreundliches und einfaches Upgrade der Kommunikations- 
endgerate, und der Komponenten des Zugangsnetzes durch transparentes Laden und Aktuallisieren von ausfuhrbarem 
50 Code. 

[0057] Auch ermoglicht sie eine automatisierte und transparente Software- Fehlerbeseitung in den Kommunikations- 
geraten, etwa das Einspielen von sogenannten Bug-Fixes. 

[0058] Nur der Vollstandiglkeit halber sei darauf hingewiesen, da3 sich alle hier beschriebenen Verfahren und Funk- 
tionen zur Realisierung als Software, insbesondere mittels eines Computerprogramms eignen. Das jeweilige Compu- 
55 terprogramm eignetsich dabei insbesondere auch als Computerprogramm Produkt auf einem Datentragergespeichert 
oder auch auf einem Tragersignal, etwa zum Down- oder auch Upload vorliegend. 

[0059] Im Folgenden wird zum besseren Verstandnis der Stand derTechnik (Fig. 1 bis 4 und 14) und die vorliegende 
Erfindung mittels nicht einschrankend zu verstehender Ausfuhrungsbeispiele (Fig. 5 bis 13 und 15) anhand derZeich- 
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nung besprochen. In dieser zeigen: 



Fig. 1 schematisch und sich selbst erlauternd die Funktionsweise Protokollstapel des Open Systems Interconnect 
Referenzmodells nach ISO 7498 nach dem Stand der Technik, wobei Pfeile Schnittstellen zwischen den 
5 Protokollschichten reprasentieren, 

Fig. 2 schematisch und sich selbst erlauternd einen Internet Protokollstapel nach dem Stand der Technik, wobei 
auch hier Pfeile Schnittstellen zwischen den Protokollschichten reprasentieren, 

10 Fig. 2a eine schematische und sich selbst erlauternde Zuordnung der Schichten eines Protokollstapels nach Fig. 
1 zu einem Internet Protokollstapel nach Fig. 2, 



Fig. 3 eine Dienst- und Technologiebezogene Unterteilung des Internet Protokollstapels, 

15 Fig. 4 eine Mobile Station mit vollstandigem TCP/IP Protokollstapel nach dem Stand der technik, 

Fig. 5 die prinzipielle Architektur einer Ausfuhrungsform des SOCKLETS-Systems nach der vorliegenden Erfin- 
dung, 

20 Fig. 6 ein SOCKLETS Encapsulation Protokoll PDU Format und Options Format nach dervorliegenden Erfindung, 

Fig. 7 ein sogenanntes Message Sequency Chart (MSC), welches zur Beschreibung von Prozessablaufen fur eine 
von der mobilen Station initiierte Verbindung dient mit den hierin emulierten Aufrufen socketQ, connect(). 
write() und read()nach dervorliegenden Erfindung, 

25 

Fig. 8 ein sogenanntes Message Sequency Chart (MSC) fur ein vom Mobile Terminal (MT) initiiertes Protokoll- 
Handover nach dervorliegenden Erfindung, 

Fig. 9 einen SOCKLETS Client mit den entsprechenden Modulen der Mobilen Station (MS) nach dervorliegenden 
30 Erfindung, 

Fig. 10 einen sogenannten Mobile Access & Routing Controller (MARC) und SOCKLETS Server nach dervorlie- 
genden Erfindung, 

35 Fig. 11 eine Queue Disziplin nach dervorliegenden Erfindung, 

Fig. 12 eine Datenpufferungsdisziplin fur gesicherte (reliable) Ubertragung nach der vorliegenden Erfindung, 

Fig. 13 ein Convergence/Adaption & MAC Multiplexing nach dervorliegenden Erfindung, 

40 

Fig. 14 eine Protokollbeendigung fur einen ausgewahlten Kanal (DCH) im UMTS-System in der Benutzerebene 
nach dem Stand der Technik namlich der Quelle: 3G TS 25.301 , Kap. 5.6.1 , dort p. 30, Figure 1 3, und 

Fig. 15 eine Einbettung einer SOCKLETS Proxy Funktionalitat in PDCP (UTRAN), UMTS Release '99 nach der 
45 vorliegenden Erfindung. 



[0060] Fig. 1 zeigt schematisch und sich selbst erlauternd die Funktionsweise Protokollstapel des Open Systems 
Interconnect Referenzmodells nach ISO 7498 nach dem Stand der Technik, wobei Pfeile Schnittstellen zwischen den 
P roto ko I Isch ichten rep rase nti eren . 
so [0061] Fig. 2 zeigt schematisch und sich selbst erlauternd einen Internet Protokollstapel nach dem Stand dertechnik, 
wobei auch hier Pfeile Schnittstellen zwischen den Protokollschichten reprasentieren. 

[0062] Fig. 2a zeigt eine schematische und sich selbst erlauternde Zuordnung der Schichten eines Protokollstapels 
nach Fig. 1 zu einem Internet Protokollstapel nach Fig. 2. 

[0063] Fig. 3 zeigt eine Dienst- und Technologiebezogene Unterteilung des Internet Protokollstapels nach dem Stand 
55 der Technik. 

[0064] Hier ist der Internet Protokollstapel in einer dienst- (links) und einer technologiebezogenen (rechts) Untertei- 
lung dargestellt. In einem Internet-fahigen Gerat konnen wir anhand der Technologie- und der Dienstunterteilung zwei 
wichtige Schnittstellen identifizieren: 
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Die Transport- bzw. Internet Service Schnittstelle (T-Schnittstelle). Sie entsprichtvorzugsweise derwohlbekannten 
Unix-, BSD-Socket Schnittstelle (BSD-Socket API) (vgl. uber Sockets: G.R.Wright, W.R.Stevens: TCP/I P-l 1 1 List ra- 
ted, Vol. 1-3, Addison-Welsey, 1995). 

5 - Die Leitungssicherungs-Schnittstelle (DL-Schnittstelle), die i.a. den Zugang von Internet Protokoll zum Zugangs- 
netz entspricht. 

[0065] Fig. 4 zeigt eine Mobile Station mit vollstandigem TCP/IP Protokollstapel nach dem Stand der Technik. Sie 
stellt die Architektur heutiger IP-basierter, drahtloser Netze dar. Sowohl in der Basisstationen als auch in den mobilen 

10 Endgeraten (Mobile Station) befindet sich ein vollstandiger TCP/IP Protokollstack. 

[0066] Die Basisstationen (auch Access Points genannt) sind bzgl. Rechenpower und Ressourcen sehr viel mach- 
tigerals mobile Endgerate und ihre Funktionalitat kann leichter erweitert werden. Daruber hinaus skalieren Computing- 
Einheiten im Festnetz, wie z.B. Basisstationen, Router, Server, bzgl. Prozessorleistung und Speicherkapazitat einfa- 
cher und leichter als die kleine mobile Gerate. Daher erscheint als logische Konsequenz, rechenintensive Operationen 

15 in das Festnetz auszulagern. Der TCP/IP Protokollstapel ist in seiner Abarbeitung sehr Ressourcen-intensiv und in 
seiner Realisierung sehrkomplex. Kleine mobile Gerate werden ausvielen, meisttechnischen Grunden, nicht allzuviele 
paralleleTCP Verbindungen mit dem Festnetz haben. Daher bringt ein vollstandiger TCP/IP Protokollstapel im kleinen 
mobilen Endgerat nicht das erwunschte optimale Leistungs-Kostenverhaltnis. 

[0067] Fig. 5 zeigt die prinzipielle Architektur einer Ausfuhrungsform des SOCKLETS-Systems nach der vorliegen- 
20 den Erfindun. Die SOCKLETS-basierte Konnektivitatsarchitektur nutzt hier folgende Grundlagen: 

1 . Die TCP Zustandsmaschine kann von dem mobilen Endgerat in das Zugangsnetz ausgelagert werden. 

2. Der Internet (TCP/IP) Protokollstapel (ein L2-7 System) kann durch eine "Zugangsnetz -Adaptionschicht" ersetzt 
25 werden, die an die jeweiligen Netzcharakteristika anpassbar ist. 

3. Im mobilen Endgerat wird eine Emulation der Socket Funktionalitat als Zugang zum Internet Protokollstapel und 
somitzu alien weiteren Protokoll-Stapeln, z.B. IPX) bereitgestellt. Das entsprechende API (API: Application Pro- 
gramming Interface) garantiert, daB alle Internet Applikationen, die die Socket Schnittstelle benutzen (das betrifft 

30 ca. 99,9% aller Internet Applikationen), ohne Modifikation laufen. 

4. Im mobilen Endgerat wird eine generische Schnittstelle zur Leitungssicherungsschicht bzw. MAC (Medium 
Acess Control) bereitgestellt, s. Fig. 9. Diese erleichtert das Injizieren von Protokollobjekten. 

35 5. In der Basisstation, oder in einer anderen Komponente des Zugangsnetzes, wird eine Relais- (Relay) Einheit 

eingefuhrt, die die Emulation der T-Schnittstelle unterstiitzt. 

[0068] Im SOCKLETS-System wird eine TCP/IP-basierte Applikationsverbindung zwischen einer Mobilen Station 
(MS) und einem Rechner im Festnetz Correspondent Host (CH) folgendermassen aufgesplittet: 

40 

1 . in eine fur das drahtlose Netz optimierte Verbindung zwischen Mobilen Station und einen Mobile Acess & Router 
Controller (MARC) und 

2. in eine TCP/IP Verbindung zwischen dem MARC und dem CH. 

45 

[0069] Eine Ende-zu-Ende TCP-Verbindung bzw. UDP-Ubertragung, wie in der Figur hier zu sehen, zwischen einer 
mobilen Station, MS, und einem Correspondent Host, CH, wird durch den Mobile Access & Router Controller, MARC. 
gesplittet. Die Verbindung zwischen MS und MARC wird durch optimierte und austauschbare Kommunikationsobjekte 
hergestellt. Nach einer "Ubersetzung" (Relay Funktionalitat des SOCKLETS- Servers im MARC) wird uber eine "nor- 
50 male" TCP-Verbindung bzw. UDP-Ubertragung zwischen MARC und CH die Konnektivitat MS <-> CH vervollstandigt. 
Durch die Architektur des SOCKLETS- Systems konnen die Kommunikationsprotokolle an die Anspruche und Mog- 
lichkeiten des jeweiligen Zugangsnetzes dynamisch angepasst und konfiguriert werden. 

[0070] Ein Socket Emulation Service stellt die T-Schnittstelle bereit. In der mobilen Station wird die Schnittstelle zu 
den Applikationen durch den SOCKLETS-Client vorzugsweise als Emulation der BSD-Socket Methoden realisiert. Der 
55 SOCKLETS-Client stellt die entsprechenden Socket Methodenaufrufe bereit, ubersetzt sie und bettet sie in Protocol 
Data Units (PDUs), s. Fig. 6, des Zugangsnetz-Adaption Protokolls (in Zugangsnetz-Adaptionschicht in der Fig. 5) ein. 
[0071] Der SOCKLETS-Server des MARC extrahiert die eingebetteten Methoden, ubersetzt diese in TCP/UDP Funk- 
tionsaufrufe, stellt (IP-) Adressierungs- und Routingmechanismen bereit und verwaltet die Transmission Control Blocks 
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der entsprechenden TCP Verbindungen. 
Socket Emulationsdienst 

5 [0072] Die Mehrheit aller Internet - Applikationen bedient sich der Socket-Schnittstelle (Internet-Protokoll Schnitt- 
stelle, hier auch T-Schnittstelle genannt) um die Internet Kommunikationsdienste (TCP/UDP/IP) benutzen zu konnen. 
Der Socket Emulationdienst implementiert die - vorzugsweise alle - Socket Funktionsaufruf; dies besonders bevorzug- 
terweise unter Berucksichtigung der Erweiterungen fur proprietare Betriebssysteme, z.B. Microsofts Window9x/NT/ 
2000/XR/ME/CE/PC. Diese Funktionsaufrufe konnen daruber hinaus vorzugsweise intern mit Qualitatssicherungs- 

10 und Verwaltungsfunktionen erweitert sein. 

[0073] Die Kommunikation zwischen dem SOCKLETS Client in der MS und dem SOCKLETS Server im MARC erfolgt 
uber eine "Fluss-ldentifikationsnummer" (Flow-ID), kurz FID. IP-Adressen und TCP bzw. UDP Service-Port Nummern 
werden auf FIDs abgebildet. Durch die FID werden Kommunikationsendpunkte bzw. Applikationen eindeutig identifi- 
ziert. Der Datenfluss innerhalb des SOCKLETS- Systems basiert auf diesen FIDs. Sie werden als 

15 

FID = H (MSJP, MS_P ; CHJP, CH_P, Key) 

erzeugt, wobei 

20 

MSJP bzw. CHJP die IP-Adressen der MS bzw. des CH sind und 

MS_P bzw. CH_P die entsprechende TCP oder UDP Ports aus dem Socketfunktionsaufruf sind. 

25 - Key ist ein eindeutiges Zertifikat wie z.B. der Geheimschlussel der USIM oder SIM Karte der MS (etwa bei UMTS 
oder GSM Geraten) oder der private Schlussel des Benutzers. Diesen Schlussel kann der Benutzer selbst gene- 
rieren oder durch eine Vertrauensinstanz (Trust Center) generieren lassen. 

H(.) ist eine Funktion, welche eindeutige Werte generieren kann, z.B. eine Hash-Funktion. 

30 

[0074] Mobile Stationen (MS), die von SOCKLETS kontrolliert werden, konnen vorzugsweise folgende Zustanden 
annehmen: 

IDLE. Der Zustand IDLE ist der Initialzustand. Vorzugsweise wird er immer dann eingenommen, wenn keine aktive 
35 Verbindung existiert. 

ACTIVE, wenn mindestens eine Verbindung zwischen MS und MARC bzw. einem CH existiert. 

TRANSIT, wenn eine Rekonfiguration des Endgerates oder eine Adaption des Zugangsnetzes stattfindet. 

40 

Zugangsnetz Protokoll (AN-Proto) 

[0075] Die Zugangsnetzschicht (Zugangsnetz-Adaptionschicht hier in Fig. 5) ist abhangig von der benutzten Uber- 
tragungstechnologie. Bietet eine Funktechnologie gesicherte Ubertragung, dann wird ein ungesichertes, einfaches 

45 Link Layer Control, LLC, Protokoll eingesetzt. Anderenfalls wird ein gesichertes Leitungssicherungs Protokoll einge- 
setzt werden, mit Flusskontrolle uber einem festem Ubertragunsfenster (sliding window), Sequenznummern und mit 
positiver oder negativer Bestatigung (Ackowledgment) und entsprechenden Retransmissionsmechanismen. 
[0076] VerschiedeneZugangsnetzprotokolle, oderTeiledavon, konnen per Download z.B. von einem externen Mehr- 
wertdienste-Anbieter geladen werden. Hierdurch kann auch das Laden eines vollstandigen TCP/I P-Stapels oder an- 

50 derer Protokollstapel, oder das Laden von Protokollobjekten fur Software Defined Radios ermoglicht werden. 

[0077] Ein "Default" Zugangsnetz-Protokollstapel, welcher fur eine globale, drahtlose Transport-Tech nologie opti- 
miert ist, ist vorzugsweise immer in "Bereitschaft". Wahrend andere Protokollobjekte entfernt werden konnen, wird das 
"Default" Protokoll oder seine Teile vorzugsweise nicht entfernt, sondern - etwa bei Bedarf - nur temporar deaktiviert. 
Dahersollte der default Zugangsnetz-Protokollstapel moglichst ressourceschonend sein. Default Zugangsnetz-Proto- 

55 kolle konnen in einer Ausfijhrungsform nach dervorliegenden Erfindungauchso realisiertsein, daGsievom "Entfernen" 
nicht ausgeschlossen sind; dabei greifen vorzugsweise dann aber hohere SicherheitsmaRnahmen. Der "Default" Pro- 
tokollstapel kann so in aller regel als "Fall-Back" Technologie dienen, etwa wenn das Laden oder die Aktualisierung 
eines neuen Kommunikationsobjekts fehlschlagt. 
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[0078] Fig. 6 zeigt ein SOCKLETS Encapsulation Protokoll PDU Format und Options Format. 



SOCKLETS Encapsulation Mechanismus 



5 [0079] Applikationsdaten werden uber die T-Schnittstelle an die entsprechende Socket Emulation ubergeben. Die 
daraus entstandene Protocol Data Units, PDUs, werden anschliessend signiert und serialisiert (marschalfing) und in 
sogennanten "SOCKLETS-PDUs" eingebettet. Die SOCKLETS-PDUs konnen unterschiedliche Formate haben. Ein 
Format der SOCKLETS-PDUs kann aus einem allgemeinen Header, gefolgt von mehreren terminalund aufgabenbe- 
zogenen Optionen, wie hier in der Fig. 6 zu sehen ; bestehen. Optionsfelder konnen Status- und Steuerinformationen, 

10 z.B. den Status der Mobilen Station und der Applikation oder auch ausfiihrbaren Code, tragen. 

[0080] Im SOCKLETS Server werden die Optionen gefullt oder abgearbeitet, die Daten serialisiert oder de-seriali- 
siert, digitale Signaturen erzeugt oder uberpruft und die wiedergewonnene PDU an den entsprechenden "Verbindungs- 
slot" des Servers ubergeben. 

[0081] Daten aus dem CH werden im MARC vom Socket Emulation Service in SOCKLETS-PDUs eingebettet, se- 
15 rialisiert, signiert und an die MS uber das drahtlose Netze geliefert. Der SOCKLETS-Client deserialisiert die Daten, 
uberpruft die Signatur und liefert die Daten an die entsprechende Applikation. 
[0082] Die Felder im Header der SOCKLETS-PDU haben folgende Bedeutung: 

Version . Gibt die Version des Protokolls wieder. Der Wert eins weist etwa auf ein Paketformat wie hier in derFigur 
20 hin. Der Wert zwei impliziert vorzugsweise ein Header Format bei dem die Felder die doppelte Bit-Lange haben. 

In Version zwei sind dann alle Felder langer: Version = 8bit, Flags=8bit, Type ID=16bit, Header Length = 16bit, 
Paket Lange = 16bit. 

Flags . Gibt Informationen fur die Steuerung der Funktionalitat der Socket Emulation. 

25 

Type ID . Gibt den Typ des Pakets wieder. Es konnen Verwaltungs- : Kontroll-, Informations- und Datenpakete 
unterschieden werden. 

HdrLen . Die Lange des Headers wird hier in ein Vielfaches von Oktetten oder von 1 6bitbzw. 32bitWerten gegeben. 

30 

Paket Lange . Das ist die Lange des gesamten Pakets (Header+Daten). 



[0083] Mehrere Optionen fur die SOCKLETS Encapsulation in die SOCKLETS-PDUs konnen definiert werden. Ei- 
nige Moglichkeiten werden in der nachfolgenden Tabelle dargestellt: 

35 

Tabelle 1: 



SOCKLETS PDU Optionen 


Optiontyp 


Erlauterung 


Quell-ID 


IP-Adresse und Port Nummer des Senders 


Ziel-ID 


IP-Adresse und Port Nummer des Empfangers 


Authentifikations-ID 


Methode zur Authentifizierung, wie z.B. durch USIM, SIM, "Simple Public Key Infrastructure 
(vgl. Ellison, RFC 2692: "SPKI Requirements", Sept 1 999)" (definiert in RFC 2692) 


Flow-ID 


Identifikation der Verbindung 


Class Definition ID 


Typ fur ausfuhrbaren Code 


Object Definition ID 


Identifikation des Objekts beim Handover 


Signature ID 


Digitale Signature oder Hash-wert des Pakets. 



[0084] Es mussen nicht alle Felder einer SOCKLETS-PDU ausgefullt sein. 

[0085] Fig. 7 zeigt ein sogenanntes Message Sequency Chart (MSC), welches zur Beschreibung von Prozessab- 
laufen fur eine von der mobilen Station initiierte Verbindung dient mit den hierin emulierten Aufrufen socketQ, connect 
55 (), writeQ und readQ, anhand dessen nun die weiteren Erlauterungen erfolgen. 
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Beispiel efnes Verbindungsaufbaus 

[0086] Instanzen, die an einem Verbindungsaufbau teilnehmen sind: 
Die Mobile Station (MS), 

der SOCKLETS-Client und der SOCKLETS-Server. Beide stellen die Socket- Emulation bereit. 



10 



15 



25 



30 



35 



40 



45 



Ein Node Manager (in Fig. 7 hier als Node-Mgr bezeichnet). Der Node-Manager ist eine uber alle Verbindungen 
buchfuhrende Instanz und Kontrollinstanz. Er kann sowohl im MARC liegen, aber auch auBerhalb, etwa in einer 
eigenen System einheit implementiert sein. 

Ein L2-7 System (TCP/IP Zustandsmaschine oder auch TCP/IP-Stack bzw. TCP/I P-Protokollstapel genannt) wel- 
ches die Schnittstelle zu dem Fixed-Netz darstellt. Es ubernimmt Routing- und Uberwachungsfunktionalitaten zwi- 
schen SOCKLETS-Server und entfernten Rechner (in Fig. 7 hier als CrspdHost bezeichnet). 



[0087] Die Socket System Funktionsaufrufe werden in SOCKLETS-PDUs eingebettet und an MARC bzw. an die 
Basisstationen iibertragen. Der SOCKLETS Server demultiplext die PDU und baut die Verbindung zum entfernten 
Host auf (Correspondent Host in Fig. 7 hier als CrspdHost bezeichnet). 
20 [0088] Ein aktiver, vom mobilen Gerat initiierter Verbindungsaufbau sieht dabei unter Bezugnahme auf die Fig. 7 
hierfolgendermassen aus: 

Schritt 1-2 Mit dem sockeQ Funktionsaufruf wird die Verbindungsintention normalerweise eingeleitet. Diese Aufruf 
ist von lokaler Bedeutung und stellt in der mobilen Station den Verbindungspunkt her. Die SOCKLETS 
Emulation liefert einen Socket-Descriptor zuriick. 

Schritt 3 Schritt 3: Die Applikation in der mobilen Station benutzt den connectQ Funktionsaufruf um eine aktive 
Punkt-zu-Punkt Verbindung mit einem Gegenpart aufzubauen (CrspdHost). Wir nehmen an, daG die 
IP-Adresse und der Dienst-Port des Correspondent Hosts der Applikation zu diesem Zeitpunkt schon 
bekannt sind. Die Socket-Emulation in der Mobilen Station (SOCKLETS-Client in Fig. 7 hier) alloziert 
eine Daten-PDU mit der Option Object Definition /Dund bettet den connectQ Aufruf in das Optionspaket. 
Die Einbettung findet vorzugsweise nach de sogenannten C-Sprache Konvention statt. Diese gibt vor 
wie Funktionsaufrufe und ihre Argumente auf den Stapel-Bereich (Stack) eines Prozessors abgelegt 
werden. Grund dafur ist, daB unter Unix-anhlichen Systemen das Binden bzw. Laden von Bibliotheks- 
objekten sehrschnell erfolgen kann. Somit kann das Abarbeiten des Objektes um einiges schnellerge- 
schehen. AnschlieRend wird ein Hash-Wert uber das gesamte Paket, unter Einbeziehung eines perso- 
nalisierten Schlussels des mobilen Gerates (SIM, USIM oder anderes Zertifikat), berechnet. 

Schritt 4 Wenn der SOCKLETS Server (SOCKLETS-Server in Fig. 7 hier) die Daten-PDU empfangt, extrahiert 
aus der Option das serialisierte Objekt und alloziert einen Transmission Control Block (s.dazu uber Sok- 
kets: G.R.Wright, W.R.Stevens: TCP/I P-lllustrated, Vol. 1-3, Addison-Welsey, 1995), TCB. TCBs bein- 
halten die TCP Zustandsmaschine und fuhren Buch uber die Verbindungen fur ihre gesamte Lebens- 
dauer. Ein INFO Paket wird zu einem "Node Manager" (Node-Mgr in Fig. 7 hier) gesendet. In dem IN- 
FO-Paket sind Informationen uber das Zugangsnetz (z.B. welche Technologie, Auslastung, usw.), uber 
das mobile Gerat und uber den Dienst enthalten. Normalerweise ist der erste Gesprachspartnerser MS 
der Node-Mgr, der die Vorarbeiten leistet um die MS uber das L2-7System mit dem externen Dienste- 
anbieter zu verbinden. Der Node-Mgr vergibt eine FlowJD, die fur die Verbindung der Applikation mit 
dem Correspondent Host innerhalb der Domane, die vom Node-Mgr verwaltet wird, eindeutig ist. 

50 Schritt 5 Der SOCKLETS-Server bereitet ein Socket mit dem Descriptor sdesc*1ur die Verbingung vor. 

Schritt 6 Anschliessend wird die TCP Verbindung mit dem Correspondent Host aufgebaut. 

Schritt 7 Der SOCKLETS-Server versucht, z.B. durch Ping (Ping ist ein IP-Mechanismus um die Existenz und 
55 Operabilitat eines IP-Rechners festzustellen. Dabei wird auch die minimale, maximale und mittlere Da- 

tenumlaufzeit berechnet. Ping ist in RFC 792 definiert [siehe IETF RFC 792 (1981): "Internet Control 
Message Protocol" (STD 5)]), die "Umlaufzeit" (Round Trip Time) von der mobilen Station zum Corre- 
spondent Host zu erfahren. Oder fragt er beim Node-Manager (Node-Mgr in Fig. 7) nach. 
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Schritt 8 Die Verbindung, die durch den Socket Descriptor sdesc* reprasentiert wird, wird auf ein Flow (FlowJD 
in Schritt 4) abgebildet. Ab nun wird die Verbindung fur diese Applikation zwischen SOCKLETS-Server 
und SOCKLETS-Client mit Hilfe dieses Flows identifiziert. Der Server bereitet eine Daten-PDU mit der 
Option Flow ID vor und sendet es zum mobilen Gerat. Ein Hash-Wert ijber das gesamte Paket, unter 
Einbeziehung eines personalisierten Zertifikates des Servers wird auch berechnet. 

Schritt 9 Der Client extrahiert die FlowJD aus der Daten PDU und signalisiert der Applikation das Ergebnis. Dabei 
wird die FlowJD auf den lokalen Socket Descriptor abgebildet. 

Schritt 1 0 Die Applikation erhalt das Ergebnis aus ihrem connectQ Aufruf - und kann nun Daten senden und emp- 
fangen. 

[0089] Im Falle, daf3 es sich um eine UDP Ubertragung handelt. wird entsprechend verfahren. 
[0090] Die Arch itektur des SOCKLETS Systems erlaubt vorzugsweise keine blockierenden System auf rufe : um Res- 
sourcen nicht unnotig lange an inaktive Prozessen zu binden. Alle blockierenden Aufrufe der Socket-Bibliothek werden 
mit Timeouts versehen und nach Zeitablauf mit einem Fehlerwert unterbrochen. So z.B. fur den readQ Aufruf (Schritt 
17 hier in Fig. 7): 

[0091] In Schritt 19 wird etwa ein Timer gestartet. Lauft dieser ab, bevor der zum Correspondent Host gerichteter 
readQ Aufruf einen Wert zuruckgeliefert hat, sendet Socket_Server zu der Applikation in der mobilen Station einen 
Fehler zuruck. Timeout-Werte werden vorzugsweise von dem Node-Mgr berechnet, der die Auslastung des Zugangs- 
netzes und die von L2-7 System durchgeleiteten Verbindungen uberwacht. 

[0092] Fig. 8 zeigt ein sogenanntes Message Sequency Chart (MSC) fur ein von der Mobilen Station (MS) initiiertes 
Protokoll-Handover wobei das MS-seitige Injizieren und Austauschen eines Protokollobjekts zu sehen. 

Rekonfiguratlon des Endgera tes/ der mobilen Station 

[0093] Die dynamische Rekonfiguraion des Endgerates, d.h. der Mobilen Station, MS, findet auf Netzwerkebene 
durch Protokoll-Handover statt. Wahrenddessen laufen bestehende Applikationen und Verbindungen unterbrechungs- 
und verlustfrei weiter. Die Aktivierung des neuen Protokollobjektes erfolgt durch den MARC bzw. die Node-Manager 
Instanz. Der Rekonfigurationsprozess lasstsich wie folgt beschreiben: 

Schritt 1 MARC fragt den Node-Manager, um zu erfahren, ob der Benutzer berechtigt ist, die entsprechende Ter- 
minalrekonfiguration durchzufuhren und ob dieser Service abonniert ist. Bei negativer Antwort wird der 
Rekonfigurationsprozess abgebrochen. 

Schritt 2 Dann wird versucht aus dem lokalen Speicher (Cache) des SOCKLETS Servers im MARC das entspre- 
chende Protokollobjekt in die MS zu laden. Wenn im SOCKLETS Server Cache keine Instanz des gefor- 
derten Protokollobjekts vorhanden ist, wird eine LookUp Anfrage an den Node-Manager gesendet. 

Schritt 3 Hat Node-Manager in seinem lokalen Speicher (permanenten oder fluchtigen) oder in einer ihm zugang- 
lichen Datenbank das geforderte Objekt nicht, wird dies nach einer Lokalisierung des entsprechenden 
Anbieters vom diesem geladen. 

Schritt 4 Anschliessend wird das Objekt in den MARC geladen, der sofort das Laden des Objektes in die MS ver- 
anlassen kann. 

Schritt 5 Schliesslich findet eine Synchronisationsphase statt, indem u.a. die Daten von und zu der Applikation 
zwischengepuffert werden bevor das neue Protokollobjekt aktiviert wird. Erst wenn die Verbindung iiber 
das neue Objekt sich stabilisiert hat, wird das "alte" Objekt, sofern es nicht um ein "default" Objekt handelt, 
deaktiviert und vorzugsweise im Speicher entfernt. 

[0094] Fig. 9 zeigt einen SOCKLETS Client mit den entsprechenden Modulen der Mobilen Station (MS). 

Endsystemvorrichtung und SOCKLETS Client 

[0095] Der SOCKLETS-Client residiert in dem mobilen Endsystem (einer Mobeilen Station [MS]) und ist das Verbin- 
gungsglied zwischen Applikationen und Medium Access Controller (MAC) der jeweiligen drahtlosen Transport-Tech- 
nologie (etwa Funk, Draht oder Licht). Die funktionale Elemente, Module und Dienste, des SOCKLETS-Client sind hier 
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in Fig. 9 dargestellt. 

[0096] Die Dienste der Ausfuhrungsumgebung des Endsystems werden von folgenden Modulen bereitgestellt: 

Handover-, Synchronisation- & Ausfuhrungskontrolle : Zentraler Prozess zu Uberwachung, Koordination und Ver- 
5 waltung der gesamten Ausfuhrungsumgebung. Die Synchronisation aller Prozesse und die Uberwachung des 

Handovers und der Datenkonsistenz finden hierstatt. 

Socket Emulation : Schnittstelle zwischen Applikation und SOCKLETS-Client. Umsetzen der Socket- Fun ktions- 
aufrufe in interne Systemfunktionen und Einbettung der Applikationsdaten in SOCKLETS-PDUs. Extrahieren der 
10 Applikationsdaten aus SOCKLETS-PDUs und Lieferung an die Applikationen. Dies ist beschrieben unter Uber- 

schriften Socket Emulationsdienst'm der Besprechung zu Fig. 5 bzw. SOCKLETS Encapsulation Mechanismus in 
der Besprechung zu Fig. 6. 

Zugangsnetz-unabhangige Dienste : Hier werden alle Funktionalitaten bereitgestellt, die von der Ubetragungstech- 
15 nologien unabhangig sind und fur alle Leitungssicherungsprotokolle Gultigkeit haben, z.B. Abbildung von Hard- 

ware-Adressen in IP-Adressen (Address Resolution Protocol, ARP, und Reverse ARP), Daten-Framing, usw. 

QoS & Datenpaket-Wartschlangen Disziplin : Qualitatssicherungsmodule fur Bandbreite, Jitter, Verzogerung 
(Delay) und Priorisierung der Daten. Dies ist beschrieben unter der Uberschrift QoS & Datenpaket-Wartschlangen 
20 Disziplin in der Besprechung zu Fig. 11 . 

Transportstapel Umschalter : In diesem Modul wird entschieden uberwelchen Protokollstapel fur das Zugangsnetz 
die Daten ubetragen werden. Derjeweilige Status (IDLE, ACTIVE, TRANSIT) dermobilen Station wird festgelegt. 
Ein Laderfur Protokollobjekte realisiert das Laden und Aktualisieren neuer Protokollobjekte bzw. das Deaktivieren 
25 nicht mehr benotigter Protokollobjekte. Eine umfassende, generalisierte Schnittstelle erlaubt das Anbinden unter- 

schiedlicher, existierender und zukunftiger Zugansnetzprotokolle. 

Datenpufferungsdisziplin : Wahrend der TRANSIT Phase werden Daten und der 

Code fur die ausfiihrbare Objekte temporar gespeichert. Nach der Aktivierung der geladenen Protokollobjekte 
30 wird die Konsistenz der Nutzdaten uberpruft und entsprechend reagiert. Der ausfuhrbare Code wird hier, bevor er 

in das Betriebssystem eingebunden wird, untersucht. Die gesicherte Dateniibertragung im TRANSIT Zustand ist 
unter der Uberschrift Datenpufferungsdisziplin zu Fig. 12 beschrieben 

Zugangsnetz Transportdienste : Diese Module / Objekte, die in dem Transportstapel Umschalter Modul einge- 
35 schlossen werden, realisieren die Transport-, Netzwerkund Leitungssicherungsfunktionalitat der jeweiligen Uber- 

tragungstechnologien. Sie stellen spezialisierte Dienste der Leitungssicherungsschicht bereit, wie z.B. Retrans- 
missions- und Datensicherungsmechanismen, Oder Paketfragmentierung. Hier residieren ladbareund austausch- 
bare Objekte fur die dynamische Rekonfiguration der mobilen Station. Link-Layer Protokolle fur verschiedene 
Medium Access Controller (MAC) werden hier gehalten. Ein Sub-Modul liefert die Funktionalitaten des "Default" 
40 Protokolls (ZN Default Transportdienste hier in Fig. 9). 

SDR Interface / MAC Multiplexer / Convergence : Abstraktionsmodul fur die Radio-Hardware. Dies ist bechrieben 
unter der Uberschrift MAC Multiplexer & Convergence Interface zu Fig. 13. 

45 [0097] Fig. 10 zeigt einen sogenannten Mobile Access & Routing Controller (MARC) und 
[0098] SOCKLETS Server. 

Rekonfiguration des Zugangsnetzes 

50 [0099] Die Rekonfiguration des Zugangsnetzes erfolgt hauptsachlich im MARC und im wesentlichen parallel und 
ahnlich wie die Rekonfiguration der mobilen Endgerate (Mobile Stationen, MS). Im MARC sind fur jede unterstutzte 
Ubetragungstechnolgie entsprechende Protokollstapel vorgesehen. Diese konnen dabei zwar installiert, nicht jedoch 
aktiviert sein. Die Aktivierung hangt davon ab, ob es eine Benutzungsanfrage gibt (vom MS oder Node-Mgr bzw. CH). 
Jede MS bekommt nach der Aktivierung des entsprechenden Objektes einen "Verbindungsslot" zugewiesen, uberden 

55 alle Kommunikation stattfindet, die dieses Objekt nutz. Nicht installierte Kommunikationsobjekte werden entwedervom 
Node-Manager oder vom externen Anbietern geladen und dann aktiviert. Der Prozess der Konfiguration des Zugangs- 
netzes, der andere vorhandene Verbindungen nicht unterbricht oder stort, laBt sich durch folgende Schritten beschrei- 
ben: 
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Schritt 1 Wenn eine Anfrage zur Aktivierung eines Protokollobjekts kommt, wird als erstes untersucht ob dieses 
Objekt in MARCs permanentem oder fluchtigem Speicher (SOCKLETS Server Cache oder Datenbank) 
vorhanden ist. 

Schritt 2 Falls das Objekt vorhanden ist, wird untersucht, ob dieses Objekt in der MS schon vorhanden ist. Im ne- 
gativen Fall wird das Objekt in die MS geladen. 

Schritt 3 Falls das Objekt in dem SOCKLETS Server Cache nicht vorhanden ist, wird es von einem externen Anbieter 
(nach einer positiven Lokalisierungsanfrage) in das Cache und anschliessend in die MS geladen. 

Schritt 4 Die MS bekommt einen neuen Verbindungsslot (ZugangsNetz ObjSlot hier in Fig. 1 0) zugewiesen, urn das 
geladene Objekt benutzen zu konnen. 

Schritt 5 Das geladene Objekt wird sowohl in MARC als auch in MS aktiviert und ggf . "alte" Objekte werden deak- 
15 tiviert bzw. aus dem Speicher entfernt. 

MARC Module und SOCKLETS Server 

[0100] Der Mobile Access & Routing Controller, MARC ist vorzugsweise in der Lage Verbindungen von mehreren 
20 mobilen Stationen und Applikationen zu verwalten und zu kontrollieren, er initiiert und uberwacht das Austauschen 
und Herunterladen (den Download) von Protokollobjekten in Mobile Stationen (MS) und zu sich selbst und schliesslich 
dient er auch als Protokoll-Relais (Relay) zum Internet. 

[0101] Die Dienste der SOCKLETS Servers werden von folgenden Modulen bereitgestellt werden: 

25 Handover, Synchronisation & Ausfiihrungskontrolle : Zentraler Prozess zu Uberwachung, Koordination und Ver- 

waltung der gesamten Ausfuhrungsumgebung. Die Synchronisation aller Prozesse und die Uberwachung der Da- 
tenkonsistenz finden hier statt. 

Quality of Service, QoS : Datenbank (Repository) mit den geltenden Abmachungen/Policies (Regeln) bzgl. Dienst- 
30 qualitat. die von den jeweiligen Netztechnologien, Benutzer- und Gerateprofile festgelegt werden. 

AAA : Rundimentare Sicherheits- und Buchfiihrungsdienste fur alle Verbindungen. 

Protokoll - Relais (Relay) : Umsetzung der proprietaren, internen SOCKLETS Verbindungen zwischen MS und 
35 MARC in entsprechende Internet Verbindungen zwischen MARC und Correspondent Host (CH). Dies geschieht 

vollig transparent zu den Applikationen, d.h. die Applikation in der Mobilen Station, MS, und ihr Gegenpart in dem 
Correspondent Host, CH, sehen nur eine Ende-zu-Ende Verbindung und kommen mit der Aufsplittung/Wiederzu- 
sammensetzung der Verbindung, die im MARC stattfindet. nicht in Beruhrung. 

40 Socket Emulation : Umsetzen der Socket- Funktionsaufrufe in interne Systemfunktionen und Einbettung der IP-Da- 

ten in SOCKLETS-PDUs. Extrahieren der Daten aus SOCKLETS-PDUs und Einbettung in Pakete des Internet- 
Protokollstapels. Dies ist beschrieben unter Uberschriften Socket Emufationsdienst in der Besprechung zu Fig. 5 
bzw. SOCKLETS Encapsulation Mechanismus in der Besprechung zu Fig. 6. 

45 Zugangsnetz- unabhangige Dienste : Hier werden alle Funktionalitaten bereitgestellt, die von der Ubetragungs- 

technologie unabhangig sind und fur alle Leitungssicherungsprotokolle Gultigkeit haben, z.B. Adressabbildungen 
von Hardware-Adressen der mobilen Stationen in IP-Adressen (Address Resolution Protocol, ARP, und Reverse 
ARP), Framing, usw. Verwaltung von Pagingfunktionen und von lokalen Multicast-Gruppen. 

50 QoS & Datenpaket-Wartschlangen Disziplin : Qualitatssicherungsmodule fur Bandbreite und Delay. Priorisierung 

der Datenstrome (Flows). Ausgleichs- (Load - Balancing) Mechanismen zur gezielten Steuerung der Bandbreiten- 
benutzung und Datenverzogerung. Umsetzung der Quality of Service Policies, die als QoS Datenbestand hier in 
der Fig. 1 0 dargestellt sind. Es werden zwei instanzen dieses Moduls benotigt: eine urn die Ubetragung von / zum 
Zugangsnetz und eine fur die Ubetragung von/zum Backbone Dies ist beschrieben unter der Uberschrift QoS & 

55 Datenpaket-Wartschlangen Disziplin in der Besprechung zu Fig. 11 . 

Dienste und Stapel fur Zugangsnetze (als Zugangsnetz Objekte hier in Fig. 1 0): Diese Module / Objekte realisieren 
die Funktionalitat der jeweiligen Ubertragungstechnologien. Sie stellen spezialisierte Dienste der Leitungssiche- 
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rungsschicht bereit, wie z.B. Retransmissionsund Datensicherungsmechanismen ; oder Paketfragmentierung. 
Link-Layer Protokolle furverschiedene Medium Access Controller (MAC) werden hier gehalten. Jeder Stapel kann 
eine maximale Anzahl von Slots verwalten. In einem Slot kann eine mobile Station "andocken" urn die Dienste 
des entsprechenden Protokolls zu benutzen. Alle relevante Zustandsdaten der Verbindungen einer mobilen Sta- 

5 tion, die einen bestimmten Protokollstapel benutzen, werden in diesem "Verbindungsslot" gehalten und von diesem 

kontrolliert. Stapel und Slots konnen genau wie eine Mobile Station drei Wirkzustande annehmen: IDLE, ACTIVE, 
TRANSIT. IDLE bedeutet daB der Stapel schon geladen aber nicht aktiviert ist. ACTIVE weist auf einen aktiven 
Stapel. der keinen, einen oder mehrere aktive Slots haben kann. In TRANSIT befinder sich ein Stapel wahrend 
Zusatzobjekte geladen / aktiviert / deaktiviert werden. Wahrend der TRANSIT Phase werden Daten und der Code 

10 fur die ausfuhrbare Objekte temporar gespeichert. Nach der Aktivierung der geladenen Kommunikationsobjekte 

wird die Konsistenz der Nutzdaten uberpruft und entsprechend reagiert. Die gesicherte Datenubertragung im 
TRANSIT Zustand ist unter der Uberschrift Datenpufferungsdisziplin zu Fig. 12 beschrieben. 

Transportstapel Connector : In diesem Modul wird fur jede zu benutzende Funkubetragungs-Technologie ein Zu- 
15 gangsnetzprotokollstapel mit mehreren Slots (Access Net Slots) bereitgestellt. Eine umfassende, general isierte 

Schnittstelle erlaubt das Anbinden unterschiedlicher, existierender und zukunftigerZugansnetzprotokolle. Das La- 
den und Aktivieren eines neuen Protokollobjektes- bzw. -stapels fuhrtzum Iniitieren und Aktivieren eines neuen 
Slots. Mehrere Slots aus unterschiedlichen Stapeln konnen einer Mobilen Station zugewiesen werden. Die Zu- 
gangsnetzstapel konnen dynamisch geladen, aktiviert bzw. geloscht werden. Durch hierarchisches Anordnen der 
20 Kommunikationsobjekte kann eine abgestimmte Partitionierung (fine granular partitioning) der Ressourcen im 

MARC erfolgen und somit eine bessere Performance erzielt werden. 

CommQbj. DB : Eine lokale Kopie (SOCKLETS Server Cache als CommObj. DB hier in Fig. 10) mit Instanzen der 
meistbenutzten Kommunikationsobjekte. Jeder aktivierte Stapel bzw. jedes Kommunikationsobjekt legt eine eige- 
25 ne Kopie in diesen Cache. Deaktivierte Objekte werden vorzugsweise nicht sofort aus dem System entfernt, son- 

dern im Cache fur eine Zeit gehalten. Dies hilft haufiges Nachladen von externen Anbietern zu vermeiden. 

Lader : Realisiert das Laden, Aktualisieren und Deaktivieren von Kommunikationsobjekten bzw. Protokollen. 

30 MAC Multiplexer/ Convergence : Abstraktionsmodul fur die Radio-Hardware. Dies ist beschrieben unter der Uber- 

schrift MAC Multiplexer & Convergence Interface in der Beschreibung zu Fig. 13. 

Internet Kommunikationsdienste : Dieses Modul stellt Standarddienste und erweiterte Dienste eines Internet Pro- 
tokollstapels bereit, wie z.B. Differential Services (IETF RFC 2475 (1998): "An Architecture for Differentiated Ser- 
35 vices"), Transportprotokolle TCP/UDP, RTP, das IP (Internet Protocol). 

Radio- Funktionen & Dienste (Dienste der Leitungssicherungsschicht): In diesem Modul werden in Abhangigkeit 
von der Backbone - Ubetragungstechnologie, wie z.B. ATM, die entsprechende standard isierten Dienste der Da- 
tenubetragungsschicht (DataLink, Logical Link Control, Medium Access Aontrol (MAC) usw.) bereitgestellt. 

40 

Backbone Dienste : Das Modul stellt die Konnektivitatsfunktionalitat fur die Anbindung des MARCs an den Back- 
bone zur Verfugung. Die Verbindung kann sowohl drahtgebunden als auch drahtlos, als Wa hi- oder Festverbindung 
erfolgen. Dies Module stellt die Schnittstelle zu alien Backbone-Protokollen, wiez.B. ATM, ISDN, Ethernet, SONET 
dar. 

45 

[0102] Fig. 11 zeigt eine Warteschlangen (Queue) Disziplin nach der vorliegenden Erfindung. 
QoS & Datenpaket-Wartschlangen Disziplin 

50 [0103] In diesem Modul werden die Qualitatssicherungsmassnahmen fur die Daten ubetragung realisiert. Jedem Da- 
tenpaket wird einer Prioritat zugewiesen (Filter). Die Prioritaten werden durch Policies (Regeln) festgelegt. Die Policies 
werden in Abhangigkeit vom mehreren Faktoren, wie z.B. Kostenmodell, Endgeratefahigkeiten, Netzwerkauslastung, 
Mehrwertdienst, bestimmt. Dabei werden die Qualitatsvorgaben fur die die gesamte Verbindungsstrecke (Mobile Sta- 
tion <-> MARC <-> Correspondent Host) berucksichtigt. 

55 [0104] Die priorisierten Pakete werden in entsprechende Daten-Warteschlangen (FIFOs) geleitet. Jedes FIFO wird 
getrennt getaktet/ geleert gemass seiner Klassen-Policies. Als Parameter fur die Festlegung der Policies und somit 
der Filter werden Bandbreite-, Jitter- und die Ubertragungsverzogerungswerte benutzt. Diese Parameter sind von den 
Charakteristik des Zugangsnetzes abhangig. Damit konnen z.B. folgende Qualitatsklassen realsiert werden: 
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Klasse A fur konstante Ubertragungsverzogerung (Delay). Diese Klasse ist fur Applikationen mit Echtzeitanforde- 
rungen notig, z.B. Sprache. Jedes Datenpaket dieser Klasse wird von einem Timer-Prozess gesteuert. 

Klasse B fur garantierte Minimum Bandbreite, fur z.B. Streaming Applikationen (Video). Ein Scheduler (Bandbrei- 
5 ten-Broker) ist fur die Einteilung der Bandbreite zwischen den Verbindungen verantwortlich. Hauptfaktoren hier 

sind die Charakterisitka des Zugangsnetzes. 

Klasse C als "Hintergrundubertragung" (Best Effort), fur Datenubertragung (Web, FTP, eMail) die keine garantierte 
Bandbreite oder zeitlichen Restriktionen oder Garantien benotigen. 

10 

[0105] Fig. 12 zeigt eine Datenpufferungsdisziplin fur gesicherte (reliable) Ubertragung nach der vorliegenden Er- 
findung. 

Datenpufferungsdisziplin 

15 

[0106] Die "Datenpufferungsdisziplin" dient der gesicherten Datenubertragung im TRANSIT Zustand. Mit Hilfe eines 
Zustandskontrollers (Zusandkontrolle) wird der Datenfluss gelenkt. 

[0107] Im ACTIVE Zustand findet keine Pufferung statt. Im TRANSIT Zustand wird der Datenfluss in Abhangigkeit 
der installierten und funktionsfahigen Protokolle gleichzeitig durch mehrere Protokollstapel durchgefuhrt. Dabei wird 
20 die Zuverlassigkeit durch eine zusatzliche Zwischenspeicherung der ausgehenden Daten erhoht. Dieser temporarer 
Puffer wird nach dem Synchronisationsprozess (siehe auch MSC Diagramm nach Fig. 8) bzw. nach Ablaut einer be- 
stimmten Zeit freigegeben. 

[0108] Hier in Fig. 12 ist zu sehen. daf3 ein Puffersch alter den Pfad regelt, den die Datenpakete zu den Speicher- 
elementen (FIFOs) nehmen mussen. Bei Verbindungen im ACTIVE-Zustand leitet der Puffersch a Iter die Daten in den 

25 Pufferspeicher 1. Geht die Verbindung in den TRANSIT Zustand uber, dann werden die Pakete parallel Liber zwei 
Wege (Schalterposition 2) geleitet, z.B. einen fur das vorhandene Protokollschema und einen fur das "Default" Proto- 
koll. Nach Installieren und Aktivieren der neuen Objekte, leitet der Schalter die Pakete uber z.B. den Weg 3. Wahrend 
des TRANSIT-Zustands konnen Pakete dupliziert werden und in einem temporaren Speicher 4 abgelegt werden. Der 
temporare Speicher wird von einem Zeitgeber uberwacht. Vorzugseise konnen die Pufferelemente, wenn erforderlich, 

30 dynamisch erzeugt und wieder freigegebenwerden. 

[0109] Die geladenen Daten werden mit Hilfe des AAA Moduls im MARC und mit Hilfe des Laders (MARC und MS) 
untersucht, es wird z.B. ihre digitale Signatur oder ihr Hashwert uberpruft und es wird ihre Schnittstelle zur Ausfiih- 
rungsumgebung gepruft. Die digitale Signatur oder der Hashwertz soil garantieren da3 der ausfuhrbare Code von 
einem vertrauenswurdigen Anbieter stammt. Die UberprLifung der Schnittstelle soli Absturze der Mobilen Station oder 

35 Beeintrachtigungen der MARC-Funktionalitat verhindern oder zumindest doch erschweren. 

[0110] Fig. 13 zeigt ein Convergence/Adaption & MAC Multiplexing nach der vorliegenden Erfindung. 

MAC Multiplexer & Convergence Interface 

40 [01 1 1] Eine Konvergenzschicht erlaubt hier dietransparente Anbindung sowohl bereits existierender MAC Protokolle 
als auch zukunftiger "Software Defined Radio" Schnittstellen. 

[0112] Die Konvergenzschicht wird in eine allgemeine (Common Part) und eine transportspezifische Schicht unter- 
teilt. 

[0113] Die Common Part Schicht, unterteilt in einem Kontroll- und einen Datenpfad, stellt die funktionalen Schnitt- 
45 stellen zurden gemeinsamen Medium-Access Diensten dar: Sicherheits- und Fehlerkontrolle, Kompressionsverfahren, 
Schnittstelle zu Handover-Mechanismen, Konfigurationsdienste fur die Funkmodems. Speichermanagement fur die 
Pakete, Segmentation und Wiederzusammenfugen von Daten, Multicast, Adressierungsfunktionen und Paging (IDLE 
Mode Control). 

[0114] Innerhalb der transportspezifischen Schicht werden Schnittstellen fur mehrere Funktechnologien. wie z.B. 
50 GSM, W-CDMA, HIPERLAN/2, IEEE802.11, Infrarot, Bluetooth bereitgestellt. Zudem beinhaltet diese Schicht vorzugs- 
weise eine "Software Defined Radio" Schnittstelle (SDR-lnterface). 

[0115] Fig. 14 zeigt eine Protokollbeendigung fur einen ausgewahlten Kanal (DCH) im UMTS-System in derBenut- 
zerebene nach dem Stand derTechnik namlich der Quelle: 3G TS 25.301 , Kap. 5.6.1 , dort Seite 30, Figure 13. Hierin 
bezeichnen UE: User Equipment, M/4C:Medium Access Control, RLC: Radio Link Control, PDCP: Packet Data Con- 
55 vergence Protocol, /VocteB=Basisstation, SRNC: Serving Radio Network Control als feststehende Begriffe i.S. der 3G 
TS 25.301 (vgl. dort Kap. 3, 7ff.). 

[0116] Fig. 15 zeigt eine Einbettung einer SOCKLETS Proxy Funktionalitat in PDCP (UTRAN), UMTS Release '99 
nach der vorliegenden Erfindung. 
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[0117] Anhand dieser Fig. 14 und 15 wird nun im folgenden eine Ausfuhrungsform der vorliegenden Erfindung am 
Beispiel einer SOCKLETS-Einbettung in UMTS besprochen. 

[0118] SOCKLETS passen sehrgut im UMTS - Rahmen und lassen sich nahtlos in UMTS einbinden. Die Einbettung 
der SOCKLETS-Funktionalitat in UMTS kann an zwei Stellen erfolgen: 

1 . innerhalb des UTRAN (UTRAN:UMTS Terrestrial Radio Access Network. Beschrieben in 3G TS 25.401 : "UTRAN 
Overall Description") mitZugang zur Uu Schnittstelle (s. Fig. 15), oder 



2. als eigenstandiger IP Netzwerk-Node, in lu-PS oder in Gn Schnittstellen (s. Fig. 15) 

[0119] Fall 1 5:Hier befindet sich der SOCKLETS Server bzw. der MARC innerhalb des UTRAN, Fig. 5, und hat 
Zugang zum Uu-lnterface. 

[0120] Wenn die SOCKLETS direkten Zugriff auf die Uu- Schnittstelle des UMTS - Systems haben konnen, so konnen 
die Protokollobjekte und somit Teile der Funktionalitat des Protokoll-Handovers in UTRAN uber PDCP (PDCP: Packet 
Data Convergence Protocol) erfolgen, da die PDCP Netzwerkschichtalle Applikationen transparentweiterreicht, wobei 
aus der Sicht von PDCP SOCKLETS naturlich nichts anderes als Applikationen sind, (dazu 3GPP TS 25.323). PDCP 
terminiert in SRNC (SRNC: Serving RNC. RNC: Radio Network Control), so daG bei einem Handover (Relocation in 
UMTS Nomenklatur) der SOCKLETS-Status weitergereicht werden kann. 

[0121] Sind die benotigten Kommunikationsobjekte (Protokoll-Proxies) noch nicht im Cache des neuen SRNC und 
ggf. des MARC, dann mussen die entsprechende Protokollobjekte geladen werden. Erst nach Installation und Aktua- 
lisierung der entsprechenden Objekte im Ziel MARC / SRNC kann die Mobile Station weiter uber diese Protokollobjekte 
kommunizieren. 1st es dagegen nicht moglich, ein Protokollobjekt in das Ziel-SRNC, bzw. MARC zu laden, dann initiiert 
MARC ein "Fall-Back" der Mobilen Station in das "Default" Protokoll (s. auch die Ausfuhrungen unter der Uberschrift 
SOCKLETS Encapsulation Mechanismus ln derbeschreibungzu Fig. 6 uber das Access Network- Protokoll). FiirPunkt- 
zu-Punkt Kommunikation sind zwei unterschiedliche Protocol-Data-Unit Formate fur PDCP definiert. SOCKLETS be- 
nutzen PDCP-Data PDUs. Nach 3GPP TS 25.323, Table 5, hat die PDCP-Data-PDU folgendes Format: 

Tabelle2: 



PDCP PDU Format (Quelle: 3GPP TS 25.323, Table 5) 



PDU Typ 



PID 



Daten 



Im PDU Typ Feld wird der Typ der PDCP-Daten-PDU nach folgender Tabelle definiert. 

Tabelle3: 



PDCP-Data-PDU Type Field. 


Bit 


PDU Type 


000 


Das PDU-ID Feld wird zur Information uber die Header-Kompression benutzt. 


001-111 


Reserviert 



Das PID Feld gibt dem PDCP-Data-PDU type wieder. 



Bit 


Beschreibung 


00000 

00001-11111 


Keine Header-Kompression 
Dynamisch ausgehandelte Kompression 



[0122] Es wird keine Vorgabe gemacht uber die Relation zwischen PID-Wert und benutzen Algorithmus oder Paket- 
datentyp. PID Werte werden dynamisch bei der Aushandlung von PDCP Parametern ausgehandlet. Damit ist es mog- 
lich neue Protokolle uber PDCP zu laden. 

[0123] Fall 2 6( SOCKLETS Server / MARC im Core-Netzwerk, Fig. 5, lu-PS-, oder Gn- Interface): 
[0124] Die lu-PS und Gn- Schnittstellen verbinden IP-basierte Komponenten, die uber das GPRS Tunnelling Protocol, 
GTP (Das GTP-U ist in 3G TS 29.060 und 3G TS 23.060 definiert.), kommunizieren. Der SOCKLETS Status kann in 
diesem Fall in GTP Pakete eingebettet werden und von MARC zu MARC geroutet werden. 
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UMTS Handover (Relocation) und SOCKLETS 

[0125] Wenn die SOCKLETS Kommunikationsvorrichtung in UTRAN eingesetzt wird, dann ist es sehr wichtig, daB 
bei einem Handover (In UMTS Nomenkaltur mit Serving RNC Relocation bzw. Routing Area oder Location Area Update 

5 benannt [3G TS 25.301, 3G TS 23.060]) zu einer neuen Zelle der SOCKLETS Status mitubertragen wird. Der 
UMTS-Handover Mechanism us ist zwar sehr komplex, fur die SOCKLETS Architektur ist aber nur ein Punkt wichtig. 
[0126] Der SOCKLETS Status kann, nachdem die "Relocation Vorbereitungsprozedur" erfolgreich abgeschlossen 
wird, in der "Relocation Commit" Nachricht eingebettet werden, die der Quell-SRNC zum Ziel-SRNC sendet. Dabei 
werden die SRNC Kontexte zum Ziel-RNC ubermittelt. Fur das 'Forwarden' (weiterreichen) des SOCKLETS-Status ist 

10 notwendig, daB bei der Serving RNC Relocation Prozedur (3G TS 23.060 Kap. 6.9.2.2) dem Ziel-RNC der SOCK- 
LETS-Status mittels RNC RAB (RAB: Radio Access Bearer) Kontext mitgeteilt wird (3G TS 23.060 Kap. 13.7, Table 
11). Dafur wird ein neuer Kontext, der die SOCKLETS Stati berucksichtigt, definiert. 
[0127] Der Relocation Prozess lasst sich nun folgendermassen zusammenfassen: 

15 1 . SRNC triggert die Ausfiihrung der Relocation. 

2. SRNC erfragt den SOCKLETS-Status (SOCKLETS spezifisch). 

3. SRNC sendet eine "Relocation Commit" Nachricht zum Ziel-RNC, mit der erweiterten RAB, die den SOCK- 
20 LETS-Status enthalt. (SOCKLETS spezifisch). 

4. Ziel SRNC empfangt die "Relocation Commit" Nachricht. 

5. Ziel SRNC setzt den SOCKLETS-Status. (SOCKLETS spezifisch). 

25 

Patentanspruche 

1 . Mobile Station (MS) zur Kommunikation mit einem Internet-Protokoll Partner (CH), die zur unmittelbaren Kommu- 
30 nikation uber ein drahtloses Zugangsnetz mit einer Protokoll Relais Station (MARC) eingerichtet ist. uber die sie 

die dann die mittelbare Kommunikation uber ein Internet-Protokoll-Netz, vorzugsweise das offentlich zugangliche 
Internet, mit dem Internet-Protokoll Partner (CH) fuhrt, dadurch gekennzeichnet, daB die Mobile Station (MS) 
mit mindestens einem Protokollobjekt wahrend des Betriebes dynamisch geladen werden kann. 

35 2. Mobile Station (MS) zur Kommunikation mit einem Internet-Protokoll Partner (CH) nach Anspruch 1, dadurch 
gekennzeichnet, daB die Mobile Station (MS) mit einem Zugangsnetzprotokollstapel als Protokollobjekt zur Ab- 
wicklung des Zugangsnetzprotokolls zur Kommunikation uber das drahtlose Zugangsnetz wahrend des Betriebes 
dynamisch geladen werden kann. 

40 3. Mobile Station (MS) zur Kommunikation mit einem Internet-Protokoll Partner (CH) nach Anspruch 1 oder 2, da- 
durch gekennzeichnet, daB die Mobile Station (MS) so eingerichtet ist, daB sie wahrend des Betriebes ohne 
Unterbrechung einer etwaigen Kommunikation mit dem Protokollobjekt, vorzugsweise Protokollstapel, geladen 
werden kann. 

45 4. Mobile Station (MS) zur Kommunikation mit einem Internet-Protokoll Partner (CH) nach Anspruch 1, 2 oder 3. 

dadurch gekennzeichnet, daB die Mobile Station (MS) so eingerichtet ist, daB sie mit mindestens zwei Proto- 
kollobjekten, vorzugsweise Zugangsnetzprotokollstapeln gleichzeitig geladen sein kann. 

5. Mobile Station (MS) zur Kommunikation mit einem Internet-Protokoll Partner (CH) nach Anspruch 4, dadurch 
50 gekennzeichnet, daB die Mobile Station (MS) so eingerichtet ist, daB sie zwischen mehreren geladenen Proto- 

kollobjekten, vorzugsweise Zugangsnetzprotokollstapeln, umschalten kann. 

6. Mobile Station (MS) zur Kommunikation mit einem Internet-Protokoll Partner (CH) nach Anspruch 5, dadurch 
gekennzeichnet, daB die Mobile Station (MS) so eingerichtet ist, daB sie von einem geladenen gerade aktiven 

55 Protokollobjekt, vorzugsweise Zugangsnetzprotokollstapel, wahrend der Kommunikation auf einen anderes gela- 

denes Protokollobjekt, vorzugsweise einen Zugangsnetzprotokollstapel, iibertragungsunterbrechungsfrei um- 
schalten kann. 
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7. Mobile Station (MS) zur Kommunikation mit einem Internet-Protokoll Partner (CH) nach einem der Anspruche 3 
bis 6, dadurch gekennzeichnet, daB die Mobile Station (MS) so eingerichtet ist, daB unterschiedliche geladene 
Protokollobjekte, vorzugsweise Zugangsnetzprotokollstapel, von der Mobilen Station (MS) auch zur Kommunika- 
tion iiber unterschiedliche Zugangnetze verwendet werden. 

8. Mobile Station (MS) zur Kommunikation mit einem Internet-Protokoll Partner (CH) nach einem der Anspruche 1 
bis 7, dadurch gekennzeichnet, da(3 die Mobile Station (MS) so eingerichtet ist, daB sie eine Internet-Protokoll 
Schnittstelle (T-Schnittstelle) aufweist, auf die auf der Mobilen Station implementierte Applikationen zugreifen 
konnen. 

9. Protokoll Relais Station (MARC) zur Kommunikation mit einer Mobilen Station (MS) iiber ein drahtloses Zugangs- 
netz einerseits und mit einem Internet-Protokoll Partner (CH) andererseits, dadurch gekennzeichnet, daB sie 
das Zugangsnetzprotokoll zur Kommunikation iiber das drahtlose Zugangsnetz in das Internet-Protokoll und um- 
gekehrt das Internet-Protokoll in das Zugangsnetzprotokoll umsetzt. 

10. Protokoll Relais Station (MARC) nach Anspruch 9, dadurch gekennzeichnet, daB sie mehrere, vorzugsweise 
unterschiedliche, Zugangsnetzprotokolle zur Kommunikation uber jeweilige drahtlose Zugangsnetze in das Inter- 
net-Protokoll und umgekehrt das Internet-Protokoll in das jeweilige Zugangsnetzprotokoll umsetzt. 

11. Protokoll Relais Station (MARC) nach Anspruch 10, dadurch gekennzeichnet, daB sie so eingerichtet ist, daB 
unterschiedliche Protokollobjekte, vorzugsweise Zugangsnetzprotokollstapel, von ihr auch zur Kommuikation iiber 
unterschiedliche Zugangnetze verwendet werden. 

12. Protokoll Relais Station (MARC) nach Anspruch 10 oder 11 . dadurch gekennzeichnet, daB sie jeweilige Proto- 
kollobjekte, vorzugsweise Zugangsnetzprotokollstapel zur Kommunikation iiber das jeweilige drahtlose Zugangs- 
netz, von einem externen Server anfordert. 

13. Protokoll Relais Station (MARC) nach einem der Anspruche 9 bis 12, dadurch gekennzeichnet, daB sie bei der 

Umsetzung des Zugangsnetzprotokolls in das Internet-Protokoll und umgekehrt des Internet-Protokolls in das 
Zugangsnetzprotokoll als Protokoll der Transportschicht zur Kommunikation uber das Internet-Protokoll Netz mit 
dem jeweiligen Internet Protokoll -Partner (CH) ein TCP-Protokoll verwendet. 

14. Protokoll Relais Station (MARC) nach einem der Anspruche 9 bis 12 ; dadurch gekennzeichnet, daB sie bei der 

Umsetzung des Zugangsnetzprotokolls in das Internet-Protokoll und umgekehrt des Internet-Protokolls in das 
Zugangsnetzprotokoll als Protokoll der Transportschicht zur Kommunikation iiber das Internet-Protokoll Netz mit 
dem jeweiligen Internet Protokoll-Partner (CH) ein UDP-Protokoll verwendet. 

15. Protokoll Relais Station (MARC) nach einem der Anspruche 9 bis 14, dadurch gekennzeichnet, daB sie so ein- 
gerichtet ist, daB sie die jeweilige Mobile Station (MS) mit einem Protokollobjekt, vorzugsweise einem Zugangs- 
netzprotokollstapel zur Abwicklung des Zugangsnetzprotokolls zur Kommunikation iiber das drahtlose Zugangs- 
netz, wahrend des Betriebes der Mobilen Station (MS) laden kann. 

16. Protokoll Relais Station (MARC) nach Anspruch 15, dadurch gekennzeichnet, daB sie so eingerichtet ist, daB 
sie die jeweilige Mobile Station (MS) mit dem Protokollobjekt, vorzugsweise Zugangsnetzprotokollstapel, wahrend 
des Betriebes der Mobilen Station (MS) ohne Unterbrechung einer etwaigen Kommunikation laden kann. 

17. Protokoll Relais Station (MARC) nach Anspruch 15 oder 16, dadurch gekennzeichnet, daB sie das jeweilige 
Protokollobjekt, vorzugsweise den jeweiligen Zugangsnetzprotokollstapel, zum Laden der jeweiligen Mobilen Sta- 
tion (MS) von einem externen Server anfordert. 

18. Protokoll Relais Station (MARC) nach einem der Anspruche 9 bis 17, dadurch gekennzeichnet, daB sie so ein- 
gerichtet ist, daB sie die Mobile Station (MS) zur Umschaltung zwischen mehreren geladenen Protokollobjekten, 
vorzugsweise Zugangsnetzprotokollstapeln, veranlassen kann. 

19. Protokoll Relais Station (MARC) nach Anspruch 18, dadurch gekennzeichnet, daB sie so eingerichtet ist, daB 
sie die Mobile Station (MS) zur Umschaltung von einem geladenen gerade aktiven Protokollobjekt, vorzugsweise 
Zugangsnetzprotokollstapel, wahrend der Kommunikation auf einen anderes geladenes Protokollobjekt, vorzugs- 
weise einen Zugangsnetzprotokollstapel, ubertragungsunterbrechungsfrei veranlassen kann. 
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Kommun ikat ion ssy stem (SOCKLETS-System) zur Anbindung von Mobilen Stationen (MS) an Internet-Protokoll 
Partner (CH), welches zumindest eine Mobile Station (MS) nach einem der Anspruche 1 bis 8 und zumindest eine 
Protokoll Relais Station (MARC) nach einem der Anspruche 9 bis 19 aufweist. 
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